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System complexity... ever increasing, it requires sophisticated 
tools for its management. And, as complexity increases, the costs 
of flawed design decisions increase with it. 

If you design... complex hardware systems, software systems, 
communications systems, or VLSI circuitry, you know the 
consequences of discovering a subtle flaw late in the develop¬ 
ment cycle. 

What if... you had an easy to use, elegant tool that could 
determine the impact of design decisions when they are made, 
not weeks or months later? 

Introducing... a multi-level simulation, modeling, and design 
evaluation tool that will let you test your ideas, not regret them: 

SES /workbench. 

Call 512-474-4526, write to us 
or check the reader response 
card for more information. 


Test the design , not just the 

Scientific and Engineering Software, Inc. 

1301 West 25th, Suite #300, Austin, Texas 78705 
Phone: 512/474-4526 Fax: 512/479-6217 

See us at the Design Automation Conference in Las Vegas, June 25-29. 





NEW FOR LAN DESIGNERS 


BEFORE 


AFTER 


Costs and delays of programming or limited 
analysis using queuing models 



Local area network (LAN) simulation-quick 
results, no programming 


See your proposed LAN perform under various workloads 

NETWORK II.5 now gives you easy-to-understand simulation 
results quickly—no programming 


W ith NETWORK II.5 you 
enter your local area net¬ 
work description. 

Simulation follows immediately 
-no programming delays. 

Easy-to-understand results 

Your reports show utilization, 
queues, execution times, response 
times, and message activity. 

Graphical reports show hardware 
layout, software data flow, and 
device utilization. 

Seeing graphical results increases 
everyone’s understanding of your 
proposed network and builds con¬ 
fidence in the analysis. 

Your system simulated 

You can simulate some portions 
of the system at a detailed level 
and others at a coarser level. 

Industry standard protocols are 
built-in-you just make a choice. 
Other protocols can be modeled us¬ 
ing powerful hardware and software 
description features. 


Free trial offer 

The free trial contains everything 
you need to try NETWORK II.5® 
on your computer. 

You may develop your own LAN 
or modify one of ours. 

Try the NETWORK II.5 ap¬ 
proach, the quality and timeliness of 
our support, the accuracy of our 
documentation, and the facilities for 
error checking -everything you need 
for a successful project. 

For 26 years CACI has provided 
trial use of its simulation software 
-no cost, no obligation. 

Act now-free training offer 

For a limited time we also 
include free training. Typical ap¬ 
plications are demonstrated there. 

Call today to avoid disappoint¬ 
ment-class size is limited. 

For immediate information 

Call Paul Gorman at (619) 
457-9681, FAX (619) 457-1184. In 
Europe, call Richard Eve on (01) 
528-7980, FAX (01) 528-7988. 


The quickest, easiest way for 
you to evaluate LAN alternatives 
is with NETWORK D.5. 


Rush information on the 
NETWORK II.5 free trial and 
training offer 

Free trial—no cost, no obligation. 

Limited offer—Act now for free training. 

Also send information on: 

□ COMNET II.5-Telecommunication 
network analysis without program¬ 
ming. 

□ Special University Offer. 
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Murat M. Tanik and Raymond T. Yeh 

*1 Q Software Evolution Through Rapid Prototyping 

Luqi 

Rapid prototyping supports software evolution as well as initial development. Computer-aided prototyping tools and object-based 
methods support evolution of both prototypes and production software. 

2 P An Object-Oriented VLSI CAD Framework 

Rajiv Gupta, Wesley H. Cheng, Rajesh Gupta, Ido Hardonag, and Melvin A. Breuer 
Object-oriented database management systems eminently support rapid prototyping, letting programmers gradually refine a subset 
of objects and operations instead of specifying and developing a complete application. 

Q Q Software Storming: Combining Rapid Prototyping and Knowledge Engineering 

Pamela W. Jordan, Karl S. Keller, Richard W. Tucker, and David Vogel 
Based on the brainstorming problem-solving technique, this system development method produces a more functional prototype in 
four months than conventional methods do in two years. 
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T.G. Lewis, Fred Handioser III, Sharada Bose, and Sherry Yang 
By showing instead of telling a program what to do, 50-90 percent of an application can be developed without explicit 
programming, increasing productivity two- to tenfold. 

Cl'l A Rapid Prototyping Facility for Flight Research in Advanced Systems Concepts 

Eugene L. Duke, Randal W. Brumbaugh, and James D. Disbrow 
NASA recognizes that the United States needs a flight-research facility dedicated to rapid avionics prototyping. 

The agency is now developing the Ames-Dryden facility to meet that need. 
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Randy Cieslak, Ayman Fawaz, Sonia Sachs, Pravin Varaiya, Jean Walrand, and Albert Li 
Prototyping is superior to analysis and simulation for studying network design and behavior, but until now it has not been cost-effective. 
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ADVANCE ANNOUNCEMENT 

IEEE Computer Society 


Conference on 

Computer Vision 
and 

pattern Recognition 

June 4-8,1989 

Sheraton Grand Hotel on Harbor island 
San Diego, California 


General Chair: 

Professor Rama Chel lappa 
Department of Electrical Engineering Systems 
University of Southern California 
LOS Angeles, CA 90089-0272 


Program Co-Chairs: 

Professor worthy Martin 

Professor John kender 

Department of Computer Science 

Department of computer Science 

University of Virginia 

Columbia University 

Charlottesville, VA 22903 

New York, NY 10027 

Tutorials Chair 

Local Arrangements Chair 

Professor Keith Price 

Professor Shankar Chatterjee 

Department of Electrical Engineering systems 

Department of Electrical and Computer Engineering 

University of Southern California 

university of California at San Diego 

LOS Angeles, CA 90089-0272 

La Jolla, CA 92093 



The Computer Vision and Pattern Recognition (CVPR) conference will begin on Sunday, June 
4th with the following tutorial sessions: 


June 4, 1989 —1:30-5:30pm 

1. Morphology and Computer 
Vision 

Professor r.m. Haralick, 
University of Washington 

2. Low and intermediate Level 
Vision 

Professor M.S. Tfivedi, 
University of Tennessee 


June 5,1989-8:30am-12:30pm 

3. Robust Methods for 
Computer Vision 

Dr. Wolfgang Forstner, 

Stuttgart University 

4. Parallel Algorithms and 
Architectures for Computer 
Vision 

Professor V.K. Prasanna 
Kumar, University of 
Southern California 


Junes, 1989-1:30-5:30pm 

5. Analog Networks for 
Computer Vision: Theory 
and Applications 

Professor C. Koch, California 
institute of Technology 

6. Model Based Vision 
Professor W.E.L. Crimson, 
Massachusetts institute of 
Technology 


Conference sessions begin at 9:00am on Tuesday June 6th and continue until 6:00pm on 
Thursday, June 8th. 


Dr. J. Feldman, ICSI, Berkeley has been invited to address the group on June 6th regarding 
Time, Space and Form in Computer Vision. The invited lecturer on June 7th is Professor 
V.S. Ramachandran, University of California, San Diego. Professor Ramachandran has been 
invited to address the issue of Visual Perception in Humans and Machines. Ideas on Schemas, 
Computer Vision and Neural Networks will be presented on June 8th by invited lecturer 
Professor M.A. Arbib, University of Southern California. 


| IEEE Computer Society The Institute of Electrical and Electronics Engineers, Inc. 



















IEEE Computer Society conference on 

Computer Vision and Pattern Recognition 

Sheraton Grand Hotel on Harbor island 
San Diego, California 
June 4-8,1989 


Registration information 


Advance Registration Fees- 

until May 8,1989 


conference Only: 

Members = $200.00 

Nonmembers = $250.00 

students = $100.00 

Tutorials Only: 

Members = $100.00 

per tutorial 

Nonmembers = $125.00 

per tutorial 

Students = $100.00 

per tutorial 

Late/On-site Registration Fees-After May 8,1989 


Conference Only: 

Members = $240.00 

Nonmembers = $300.00 

Students = $105.00 

Tutorials Only: 

Members = $125.00 

per tutorial 

Nonmembers = $150.00 

per tutorial 

Students = $125.00 

per tutorial 


Student registration includes attendance at sessions, one copy of proceedings and admission to the 
reception and banquet. 


A block of sleeping rooms is being held for your use at the host hotel, the beautiful Sheraton 
Grand Hotel on Harbor island. Please mention that you are attending CVPR and you will be registered 
at the conference rate of $102.00 for single or double accommodations. Reservations can be made 
by contacting the Sheraton Reservation Center, 1380 Harbor island Drive, San Diego, CA 92101, 

(619) 692-2265. 


For a copy of the complete CVPR advance program, please contact: Conference 
Department, IEEE Computer Society, 1730 Massachusetts Avenue, NW, Washington, DC 
20036. Phone Number: (202) 371-1013. Fax Number: (202) 728-9614. 

The following topics will be addressed during paper sessions, June 6th through June 8th. 

. Edge Detection • Range Data: Generation • Object Recognition 

. Shape From ... and Processing • Navigation 

• Feature Extraction • image and Texture • Preprocessing 

• Motion Segmentation • Applications 

. Morphology, Neural Networks • Monocular, Polarization Cues • Architecture, Systems 

• Stereo 

CVPR promises to provide an excellent opportunity for increased research interactions and 
continual education. Plan to attend! 


On Monday, June 5,1989, the IEEE Computer society workshop on Artificial intelligence 
for Computer Vision will be conducted at the Sheraton Grand Harbor. The workshop, 
co-chaired by Professor Jake Aggarwal and Azriel Rosenfeld, consists of seven invited talks 
and a panel session. Additional information on registration can be obtained from the 
IEEE Computer Society Office or from the CVPR general chair, Professor Rama Chellappa. 


IEEE Computer Society The Institute of Electrical and Electronics Engineers, Inc. 
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& IntegrAda 


...the first completely integrated Ada Program¬ 
ming Support Environment priced for the individual 
programmer on a PC. Designed for the novice as 
well as the software engineer. 


cedure TEST is 
sk CONTROLLER is 
ntry TBD(_ :in oi 
d CONTROLLER; 


Validated Production Compiler 
Use on 8086,80186,80286,80386. 

Full 640KB .EXE Programs 
No Extra Memory Required 
No Math Coprocessor required. 

On-Line Library Management 

Math, Text, Console Packages included 

Multiple File Code Retrieval 

Full-Color, Full Featured Editing 

Selectable Function Keys 

Ada Subprogram and Package Generation 

Ada Type Generation 

Ada Sensitive Cursor 

Interactive Cursor Error Correction 

Interface to Ada Design Language (ADADL) 

Ada Standard Pretty Printer 

DoD 2167 Documentation Features 

Optional On-Line Ada Training Course 

No Run-Time Royalties 


" Compiler, linker, environment with editor, pretty printer, 
and lots of libraries the best buy " ...Computer Language. 
“Turbo Ada?"...the first choice among the half dozen 
compilers now on the market " ...PC Week. 

“Full color, user-friendly integrated environment for the PC 
competes with C and Pascal" ...Ada Strategies 




ACTCCH (619)755-1277 $795.00 


Preparing for the technology of the 1990s 

Computer Society 
adopts objectives 

I n December 1988, the Computer Society reached a mem¬ 
bership of 100,579. This makes us “Number One” in 
membership for all organizations of computer profes¬ 
sionals. It also means that we must continue to provide our 
members with quality programs, publications, and services. 

The society’s mission is to “advance the theory, practice, 
and application of computer and information processing 
science and technology and maintain a high professional 
standing among its members.” To this end, it promotes 
cooperation and exchange of technical information among its 
members, holds meetings for presentation and discussion of 
technical papers, publishes journals, and otherwise provides l 
for the needs of its members. In scope, the society encom¬ 
passes all aspects of theory, design, practice, and application 
relating to computer and information processing science and 
technology. 

Another milestone reached during 1988 was the formula¬ 
tion of objectives to help us “Be Number One.” These objec¬ 
tives were adopted at the March 3, 1989, meeting of the 
Board of Governors. The objectives can now be used to plan 
and monitor current programs as well as those we are plan¬ 
ning for the future. Since our membership is worldwide, our 
global objectives must encompass all interest groups. I believe 
the objectives do that but ask you to tell me whether those 
that follow are complete. 

The board formulated and adopted six expanded objectives 
to accomplish the meta objective to “Be Number One”: 

• Provide a full range of services appropriate to the mem¬ 
bership 

• Adapt to (keep pace with) changing technology 
• Achieve and maintain the highest quality in all programs 
• Be the representative society of computer professionals 
• Maintain financial viability 
• Achieve recognition in the scientific/technical com¬ 
munity 

Services. The first of the above objectives — provide a full 
range of services appropriate to the membership — focuses < 
on three types of services: individual, professional, and 
industry/government/academic. 

• Individual services. The Computer Society offers a full 
range of services to the individual. These services include 
publications, conferences, tutorials, educational 
materials, professional contacts (networking), informa¬ 
tion databases (new for the Computer Society), scholar¬ 
ships, chapters (student, city, etc.), and products 
(software, tools exchange, tools fair). 

• Professional services. On the professional level, the Com¬ 
puter Society offers awards and other avenues for peer 
recognition. 

• Industry/government/academic. Services in this area 
include our standards activities and consulting for other 
bodies. 
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Technology. To advance our second objective — adapting 
to changing technology — the society will 

• Monitor evolution of current hardware and software 
technology 

• Predict new or emerging technology 

• Redirect our boards — Technical Activities Board, Stan¬ 
dards Activities Board, Area Activities Board, etc. — to 
respond to or cover new or evolving technology 

• Plan new publications 

• Split current publications, increasing frequency and/or 
dividing and creating new publications 

Quality. Achieving and maintaining the highest quality in 
all programs, the society’s third objective, will require 

• Establishing self-assessments/surveys on a periodical 
basis 

• Identifying competitors and making comparisons 

• Establishing quality criteria 

Representation. Our fourth goal — to become the repre¬ 
sentative society of computer professionals — means that we 

• Define “computing professionals” 

• Determine their needs 

• Define appropriate services 

• Go after them 

Finances. The fourth objective is to assure continued ser¬ 
vices by maintaining financial viability. To do this, the soci¬ 
ety will 

• Establish financial planning procedures for the society 
and its boards 

• Maintain adequate reserves 

• Subscribe to a balanced budget policy 

• Capitalize on society products, services, and expertise 

• Establish periodic marketing studies for the society and 
its boards 

Recognition. The final goal — achieve recognition of the 
Computer Society as a major force in the larger scientific 
technical community — means that we must 

• Promote the society to other bodies, that is, other socie¬ 
ties, government agencies, and other professional com¬ 
munities 

• Retain/expand visibility of the society to other associ¬ 
ations 

• Establish a body within the Computer Society responsible 
for external relations as a continuous activity 

T he society’s leaders adopted these objectives to estab¬ 
lish a clearer vision of the future and would like to 
know what you think about them. Please drop me a 
note with your comments or suggestions for additional 
objectives. 

Kenneth R. Anderson 
Siemens Research 
755 College Rd. East 
Princeton, NJ 08540 



Write for a free Catalog 


The first of its kind... 

A GUIDEBOOK TO 
FORTRAN ON 
SUPERCOMPUTERS 

John M. Levesque and 
Joel W. Williamson 

November 1988, 218 pages 
$39.95/ISBN: 0-12-444760-0 


Suitable as a self-tutorial. 

INTRODUCTION 
TO PARALLEL 
PROGRAMMING 

Steven Brawer 

May 1989, c. 409 pages 
$39.95 (tentative) 

ISBN: 0-12-128470-0 


Create, modify, and experiment 
with today’s human-computer 
interfaces.. . 

CREATING USER 

INTERFACES 

BY DEMONSTRATION 

Brad A. Myers 

1988, 300 pages, $29.95 
ISBN: 0-12-512305-1 


ACADEMIC PRESS 

_ Jiarcourt Brace Jovanovich, Publishers - 

Book Marketing, #10059,1250 Sixth Ave., San Diego, CA 92101 

CALL TOLL FREE 1-800-1*1-5068 


First two volumes of the new 
series Computer Graphics — 
Technology and Applications... 

INPUT DEVICES 

edited by 
Sol Sherr 

1988, 320 pages, $54.95 
ISBN: 0-12-639970-0 


OUTPUT HARDCOPY 
DEVICES 

edited by 

Robert C. Durbeck 
and Sol Sherr 

1988, 544 pages, $59.95 
ISBN: 0-12-225040-0 


Tools and Techniques 
From Academic Press 
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Baltimore Convention Center 
Baltimore, MD • June 12-16, 1989 


SUMMER 1989 USENIX TECHNICAL 
CONFERENCE AND EXHIBITION 


TUTORIALS 

Presented by leading UNIX® experts, the tutorials 
provide a detailed examination of several UNIX 
topics including: 


• UNIX internals 

• Operating Systems 

• Networking 

• Windowing Schemes 

• System/Network 
Administration 


• Software Development 

• Writing Device Drivers 

• Graphics 

• Typesetting 

• Security 

• Compilers 


Software professionals and technical managers will 
benefit from attending these continuously "sold out” 
offerings. 


TECHNICAL SESSIONS 

Exploring issues of interest to the UNIX technical 
community, these sessions provide a forum for the 
presentation and discussion of work in all areas of 
UNIX-related research and development. Topic areas 
are expected to include: 

• Performance : 

Kernel enhancements 
Compute and file servers 
Scaling issues resulting 
from more MIPS 


• Trends: 
Lightweight 
processes 
Neural networks 
Object-oriented 
extensions 


• Filesystems: CDROM, 
WORM, network, archival 

• Networks: WAN, LAN, 
UUCP OSI, distributed 
services 

• User interfaces 

• High reliability/ 
availability, 
fault-tolerance 


• Heterogeneous 
environments: 
DOS/UNIX migration, 
mainframes 

• Media: graphics, 
video, audio, art, 
education 

• System/network 
administration 
and security 


THE SPONSOR 

The USENIX Association fosters innovation in 
software with a historical and present UNIX bias. 
USENIX promotes communication and idea sharing, 
encourages pragmatic research, and sponsors prob¬ 
lem-solving activities that impact the UNIX 
community. 


I nr 1 k : : The Professional 
and Technical 

ULlllll UNIX Association 

For complete conference details, call: 

(714) 588-8649, or write: 

USENIX Conference Office 
22672 Lambert Street, Suite 613 
El Toro, CA 92630 


UNIX is a registered trademark of AT&T. 

























Guest Editors’ Introduction 

Rapid 
Prototyping 
in Software 
Development 

Murat M. Tanik, Southern Methodist University, and Raymond T. Yeh, ISSI 



T he predominant model for cur¬ 
rent application development is 
the phased refinement approach. 
In this approach, all system functionality 
is specified in the first step of develop¬ 
ment, and subsequent implementation 
phases add prescribed design details. 
This approach is criticized for its high 
cost of maintenance, for lack of motiva¬ 
tion in using abstract tasks in early 
phases of development, and for compli¬ 
cations in system integration. 

Prototyping, as an evolutionary sys¬ 
tems development paradigm in which a 
number of nonstandard concepts work 
together, promises to achieve effective 
evolution of integrated hardware/soft¬ 
ware systems. 

Prototyping 

Prototyping is the process of develop¬ 
ing a scaled-down version of a system to 
use in building a full-scale system. Com¬ 
puter-aided rapid prototyping (fast 
prototyping) promises to provide a 
means for building the scaled-down ver¬ 
sion of a system more quickly than using 
conventional approaches. The final prod¬ 
uct of the prototyping activity is a work¬ 
ing model that can be used for many 
purposes, such as requirements valida¬ 
tion, feasibility study of a complex sys¬ 
tem, behavioral specification of a sys¬ 
tem, and functional specification of a 
system design. 

To describe the role of prototyping in 
software development, we must first dis¬ 
cuss a process model, shown in Figure 1. 


L 


□ 



Figure 1. Process model for software/system evolution. 



Figure 2. Detailed process model. 


The process model differs from the 
traditional phased approach in that it 
concentrates on the hard problems of 
systems development, namely: require¬ 


ment specification, and design rather 
than coding. Equally important, valida¬ 
tion, evaluation, and hardware/software 
trade-off analysis are all part of the 
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Figure 3. General structure of prototype design environment. 


development process - they do not just 
follow completion of the development in 
each phase. As you can see, rapid proto¬ 
typing works as an integral part of this 
model by providing the indicated types 
of continuous feedback information as 
rapidly and efficiently as possible. A 
more detailed version of the process 
model appears in Figure 2. 


Rapid prototyping 
support 

To appreciate the rapid prototyping 
paradigm, you must view software de¬ 
sign as an iterative decision-making 
process. Abstract design decisions are 
made to decompose a set of requirements 
specifications into certain abstract de¬ 
sign components. We can view a soft¬ 
ware system design as a collection of 
abstract design components. Data, func¬ 
tion, and control abstractions are primi¬ 
tives with which to represent a software 
system design. 

The evolutionary development of a 
software system design requires an inte¬ 
grated design support environment. A 
typical structure for a design environ¬ 
ment that supports the rapid prototyping 
paradigm and the evolution process 
model is shown in Figure 3. 


S ince the early 1960s, engineers 
and mathematicians have brought 
fundamental ideas into software 
development from other disciplines as 
well as developing new ones. The time 
has now come to introduce the systems 
view and theory into the building of soft¬ 
ware and software development environ¬ 
ments. The rapid prototyping paradigm 
provides an evolutionary software devel- 



Murat M. Tanik is an associate professor and 
director of the Software Engineering and 
Knowledge-Based Systems research group at 
Southern Methodist University. He is conduct¬ 
ing research in the development of a novel sys¬ 
tem-design environment with support from 
many sources. 

Tanik received a PhD in computer science 
from Texas A&M University. He has written 
extensively on programming languages and 
software-development support environments. 


Readers may contact Tanik at the Computer 
Science and Engineering Dept., School of En¬ 
gineering and Applied Science, Southern 
Methodist University, Dallas, TX 75275-0122. 


opment framework in which the systems 
view of software design is maintained 
throughout the development phase. □ 
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About the cover: Biosphere II - a prototype for the future 


Nancy Hays, Computer staff 

If you wanted to build a prototype of 
Earth, how would you go about it? You 
would need a physically isolated, self-suf¬ 
ficient ecosystem big enough to maintain 
itself over time and small enough that you 
could afford the cost. Once you suc¬ 
ceeded, you would have a biosphere that 
you could recreate in space, on Mars - or 
in the Arizona desert. 

Going up near Oracle, Arizona, is Bio¬ 
sphere II, a soon-to-be self-sustaining 
world in 5 million cubic feet. The system 
is scheduled to close for two years begin¬ 
ning in September 1990, with no exit for 
its human inhabitants except in case of 
medical or family emergencies. 

This miniature replica of Biosphere I 
(Earth) ranges from desert to tropical rain¬ 
forest in 2.5 acres. The model shown be¬ 
low illustrates how the biomes lead from 
one to the next, with the desert at the low¬ 
est elevation and the rainforest at the 
highest. The atmosphere is one continu¬ 
ous system, with air circulation accom¬ 
plished by convection prompted by differ¬ 
ences in altitude, temperature, and some 
built-in structural diversions. Variable vol¬ 
ume chambers, or “lungs," connected to 
Biosphere II accommodate the expansion 
and contraction of air caused by changes 
in temperature. This prevents breakage of 
the system's glass or seals - a vital con¬ 
sideration in a hostile environment such 
as space. 

To understand Biosphere M's self-suffi¬ 
ciency, consider the water cycle. A 
stream flows from a mountain in the rain¬ 
forest, along the savannah plain, into the 
fresh water marsh, the salt water marsh, 
and the ocean. Water evaporates from the 
ocean and is carried by air currents back 
to the rainforest, where cooling coils con¬ 
dense it back into the stream and the rain¬ 
forest. 

Each area within Biosphere II will sup¬ 
port plants and animals native to the envi¬ 
ronment. A separate building for the hu¬ 
mans, or Biospherians, includes living 
quarters and research facilities. An inten¬ 


sive-agriculture area will supply most of 
the food the Biospherians will eat. 

According to its creators at Space Bio¬ 
spheres Ventures, this massive prototype 
will provide a tool for us to study our own 
biosphere, teach us how ecological tech¬ 
nics can help us manage our natural re¬ 
sources, and serve as a prototype for 
space stations or settlements. 

The project began in December 1984 
with a conference and workshop. Funded 
by venture capital of $30 million, the Bio¬ 
sphere II project is a joint venture of Deci¬ 
sions Team Inc. and Decisions Invest¬ 
ment Corp. It is located at the SunSpace 
Ranch Conference center north of 
Tucson. 

Margret Augustine serves as chief ex¬ 
ecutive officer of Space Biospheres Ven¬ 
tures and project director of Biosphere II. 
She and architect Philip Hawes designed 
Biosphere II. 

The design and engineering of Bio¬ 
sphere II is complete. Construction 
started in January 1987. To assist in the 
design and test phases, SBV uses a 
smaller prototype at the Biospheric Re¬ 
search and Development Center. The Bio¬ 
sphere II Test Module provides a sepa¬ 
rate ecosystem and serves as a prototype 
for Biosphere II. SBV researcher Abigail 
Ailing inhabited the Test Module from 
March 8-13 in a successful closed system 
experiment. SBV plans other trial closures 
before the final closure of Biosphere II. 
These experiments test materials and 
techniques, including the computer-based 
monitoring systems and the “lungs.” 

Biosphere II researchers use comput¬ 
ers extensively. The individual scientists 
work with personal computers that bridge 
to Unix workstations and file servers. The 
systems run parallel networks in what is 
essentially a distributed campus setup, 
according to Norberto Alvarez-Romo, di¬ 
rector of cybernetic systems for SBV. The 
redundancy and power provided by the 
network have meant that only now is Al¬ 
varez-Romo considering moving to a 
larger system. Minicomputers already 
handle accounting and administration. 


Software ranges from spreadsheets, 
communications, databases, and CAD 
programs on the PCs to a real-time expert 
system. The expert system allows the 
Biosphere II staff to design systems, 
simulate their behavior, redesign, create 
what-if scenarios, and evaluate fault 
modes. The staff can model energetics to 
gain more efficiency, as well as investi¬ 
gate ways to cope with information trans¬ 
fer. 

According to Alvarez-Romo, the expert 
system software eases the process of 
moving from simulation to design to im¬ 
plementation nearly to the point of flipping 
a (software) switch to implement a de¬ 
sign. 

Microcomputer-based sensors in Bio¬ 
sphere II collect data on air and soil tem¬ 
peratures, humidity, and movement. The 
data feeds into a database of raw, un¬ 
processed historical data. A second data¬ 
base contains processed historical data. 

Alvarez-Romo stressed that the Bio¬ 
sphere II project considers computers and 
software to be tools for people to use in 
their research and to interface with other 
people, systems, and biospheres. Once 
Biosphere it is closed, two independent 
life systems - the Biospherians and those 
outside of Biosphere II -- will communi¬ 
cate using computer systems and audio¬ 
visual equipment. 

This parallels the situation that would 
exist if people on Earth established a 
space station or a settlement on another 
planet. The separate biospheres would 
communicate electronically. The margin 
for error would be much less than exists 
for Biosphere II because of the cata¬ 
strophic consequences of failure in a 
harsher environment than that provided 
by the Arizona desert. 

Nonetheless, the lessons Biosphere II 
can teach us have already begun. That it 
can be constructed at all demonstrates 
the value of simulating and testing before, 
during, and following design and implem¬ 
entation. This prototype might well show 
us how to safely manage our own bio¬ 
sphere. 











NEW: lst-CLASS HT. 

EXPERT SYSTEMS WITHOUT PROGRAMMING. 
HYPERTEXT WITHOUT HYPE. 


^^There’s been a lot of talk lately 
about hypertext and expert systems. 

Now there’s finally a product that does 
justice to both. 

■■ Introducing lst-CLASS HT. 

The first expert system product to com¬ 
bine the power and accessibility of the 
lst-CLASS line with the flexibility of 
hypertext search and retrieval. 

The power you need. Without 
the programming. With lst-CLASS 
HT, you can capture specialized exper¬ 
tise quickly and easily- without a major 
investment in hardware or software. The 
powerful lst-CLASS approach requires 
no programming or artificial intelligence 
experience- yet offers rich rewards to 
those who have it. And the flexible HT 
functionality unlocks a whole new range 
of options for developers and end users 
alike. 

■Hi A full featured, high perform¬ 
ance package. lst-CLASS HT com¬ 
bines the features you need with an ex¬ 
ceptional degree of conceptual flexibil¬ 
ity. With multiple knowledge represen¬ 
tations, interfaces to other programs, 
graphics, and a variety of data formats 
(including ASCII download, dBase® and 
Lotus 1-2-3®), lst-CLASS HT has the 
best combinations of features you’ll find 
in the expert system marketplace. Add 


the opportunity to browse through mul¬ 
tiple levels of text- then immediately 
act on what you find- and we’re sure 
you’ll agree that lst-CLASS HT is the 
first truly grown-up hypertext/expert 
system package. 

■■■ Benefits you’ll see right away. 

Because 1 st-CLASS HT is so easy to 
use, it starts delivering benefits right 
away. More accurate, consistent deci¬ 
sions. Reduced costs in manufacturing 
and customer service. Easier trouble¬ 
shooting by entry level staff. And better 
use of the time and talents of senior 
personnel. 

You’ll be joining over 7500 lst- 
CLASS users from startups to Fortune 
500 companies like Chrysler, Du Pont, 
and IBM by using lst-CLASS HT. So 
why settle for less? If you’re serious 
about expert systems, and serious about 
hypertext, check out lst-CLASS HT 
today. 

Just $20 gets you a tutorial 
package. It has everything you need to 
get moving fast. And just $2495 gets 
you lst-CLASS HT itself. 

IHWhy wait? Call now to order 
your tutorial package. 

Toll-free: 1-800-872-8812. 
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Software Evolution 
Through Rapid 
Prototyping 


S oftware evolution refers to all ac¬ 
tivities that change a software sys¬ 
tem, including responses to re¬ 
quirements changes, improvements to per¬ 
formance or clarity, and repairs for bugs. 
The older term “maintenance” refers to the 
same activities in the context of the tradi¬ 
tional life cycle, with a connotation that 
maintenance is done after the initial devel¬ 
opment. In more recent process models 
such as rapid prototyping, evolution activi¬ 
ties are interleaved with the initial develop¬ 
ment and continue after the delivery of the 
initial version of the system. Since soft¬ 
ware evolution accounts for more than half 
of the total software cost, great interest has 
focused on reducing the effort required. 
Prototyping provides one promising ap¬ 
proach to achieving this goal. 12 

In this article, a prototype is a concrete 
executable model of selected aspects of a 
proposed system. Rapid prototyping is the 
process of quickly building and evaluating 
a series of prototypes. 

Figure 1 illustrates the iterative proto¬ 
typing cycle. The user and the designer 
work together to define the requirements 
and specifications for the critical parts of 
the envisioned system. The designer then 
constructs a model or prototype of the 
system in a prototype description language 
at the specification level. The resulting 
prototype is a partial representation of the 
system, including only those attributes 
necessary for meeting the requirements. It 
serves as an aid in analysis and design 

May 1989 


Luqi 

Naval Postgraduate School 



Rapid prototyping 
supports software 
evolution as well as 
initial development. 

Computer-aided 
prototyping tools and 
object-based methods 
support evolution of 
both prototypes and 
production software. 


rather than as production software. 

During demonstrations of the prototype, 
the user evaluates the prototype’s actual 
behavior against its expected behavior. If 
the prototype fails to execute properly, the 
user identifies problems and works with 
the designer to redefine the requirements. 
This process continues until the user deter¬ 
mines that the prototype successfully cap¬ 
tures the critical aspects of the envisioned 
system. 

The designer uses the validated require¬ 
ments as a basis for designing the produc- 
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tion software. Additional work is often 
needed to construct a production version of 
the system. For example, the prototype 

(1) might not include all aspects of the 
intended system, 

(2) might have been implemented using 
resources that will not be available 
in the actual operating environment, 

(3) might not be able to handle the full 
workload of the intended system, or 

(4) might meet its timing constraints 
only with respect to linearly scaled 
simulated time. 

Experience with production use of a deliv¬ 
ered system often leads to new customer 
goals, triggering further iterations of the 
prototyping cycle. 

The traditional model of software devel¬ 
opment relied on the assumption that de¬ 
signers could stabilize and freeze the re¬ 
quirements. In practice, however, the de¬ 
sign of accurate and stable requirements 
cannot be completed until users gain some 
experience with the proposed software 
system. Thus, requirements often must 
change after the initial implementation. 

In traditional approaches, these require¬ 
ments changes trigger changes to the pro¬ 
duction version of the system during the 
maintenance phase. In prototyping ap¬ 
proaches, an appreciable fraction of the 
requirements changes trigger changes in a 
prototype version of the system. This is 
useful because a prototype description 
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Figure 1. The prototyping cycle. 


(1) is significantly simpler than the 
production code, 

(2) is expressed in a notation tailored to 
support modifications, and 

(3) is suitable for processing by soft¬ 
ware tools in a computer-aided 
prototyping environment. 

These factors make it possible to modify a 
prototype more easily than a production 
version of the system. They make proto¬ 
typing especially attractive for unfamiliar 
application areas with uncertain require¬ 
ments. 

In the approach to rapid prototyping we 
will look at here, software systems are 
delivered incrementally and requirements 
analysis continues throughout the process, 
interleaved with implementation and evo¬ 
lution.' We will focus on reducing require¬ 
ments errors through prototyping before 
undertaking the incremental implementa¬ 
tion effort for each deliverable version of 
the system. Incremental delivery lets users 
gain early experience with the software in 
the actual production environment. It also 
lets developers adjust the requirements to 
reflect the effects of the initial versions of 
the system on the customers’ perceptions 
of their problems. Thus, incremental deliv¬ 
ery extends the advantages of prototyping 
to the production environment. 

The problems of software evolution are 
especially prominent during rapid proto¬ 
typing because prototypes are subject to 
frequent and repeated changes. The poten¬ 
tial benefits of prototyping depend criti¬ 
cally on the ability to modify the proto¬ 
type’s behavior with substantially less 
effort than required to modify the produc¬ 
tion software. Computer-aided prototyp¬ 
ing and object-based prototyping provide 
the solutions to this problem. Computer- 
aided prototyping provides mechanical 
assistance, and object-based prototyping 
provides conceptual simplicity. 

Computer-aided rapid prototyping im¬ 
proves the efficiency and accuracy of 
evolutionary development by introducing 
software tools that assist the designer in 
constructing and executing the prototype 
quickly and systematically. These tools 
make it attractive to use prototypes for 
evaluating evolutionary changes after a 
version of the system has been delivered as 
well as for the initial version. 

Object-based prototyping is based on 
data abstraction and inheritance. Objects 
encapsulating the data in the prototype 
system serve as the basis for design and 
implementation. Since the data in an appli¬ 
cation is generally more stable than the 


processing steps, this leads to system de¬ 
scriptions that are easier to modify than 
those based primarily on procedural ab¬ 
stractions. Inheritance helps to reduce the 
labor involved in constructing a system by 
allowing inclusion of common aspects of 
the code in many different contexts with¬ 
out explicitly repeating the details. Objects 
also provide convenient components for 
code reuse, parallel execution, and version 
control. Thus, object-based approaches 
make prototypes more flexible and auto¬ 
mation easier to achieve. 4 

Evolution based on the bare program 
code is very difficult or impossible to 
achieve, because we need information 
about the requirements, specifications, and 
design to change the code without damag¬ 
ing it. Most tools supporting evolution at 
the program level are primitive and lan¬ 
guage specific, such as facilities for gener¬ 
ating cross-reference listings and for edit¬ 
ing and storing different versions of pro¬ 
gram documentation. While such facilities 
can reduce the mechanical work involved, 
few software maintenance tools operate on 
the semantic level and few good ideas 


address the general software maintenance 
problem. To support the software evolu¬ 
tion process, tools operating at the seman¬ 
tic level should help manage the relation¬ 
ships among the implementation, the 
prototype description, and the require¬ 
ments. 

Computer-aided 
prototyping tools for 
evolution 

An integrated set of computer-aided 
software tools, the Computer-Aided Proto¬ 
typing System (CAPS), 5 has been designed 
to support prototyping of complex soft¬ 
ware systems, such as control systems with 
hard real-time constraints. The require¬ 
ments for such systems are especially dif¬ 
ficult to determine, and their feasibility is 
hard to establish without constructing an 
executable model of the envisioned sys¬ 
tem. 6 

If carried out manually, the prototyping 
process has limited benefits because of the 
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Figure 2. Main Computer-Aided Prototyping System tools. 


time and effort involved. CAPS can in¬ 
crease the leverage of the prototyping strat¬ 
egy by reducing the effort the designer puts 
into producing and adapting a prototype to 
perceived user needs. 

The evolution of a prototype starts after 
one pass through the prototyping cycle 
shown in Figure 1. The analysts have de¬ 
termined the initial requirements by talk¬ 
ing to the customer, constructed an initial 
prototype, and demonstrated it to the cus¬ 
tomer, who finds some of the prototype’s 
behavior unacceptable and requests modi¬ 
fications. 

Initially, the facilities provided by 
CAPS help adapt the prototype to the new 
requirements. We can implement modifi¬ 
cations to the production software by using 
CAPS to 

(1) add changes to prototype systems, 

(2) retrieve software components from 
the software base, 

(3) generate production code if needed, 

(4) assemble production systems 
through the prototyping cycle, and 

(5) manage the process using the proto¬ 
typing database. 

The main components of CAPS are a 
special prototyping language and a set of 
tools, illustrated in Figure 2. The main 
subsystems of CAPS are the user interface, 
the software database system, and the 
execution support system. The rest of this 
section describes these components in 
detail. 

Prototyping language features sup¬ 
porting modifications. CAPS tools com¬ 
municate by means of the Prototype Sys¬ 
tem Description Language (PSDL), 7 
which integrates the tools and provides the 
prototype designer with a uniform concep¬ 
tual framework and a high-level descrip¬ 
tion of the system. PSDL supports frequent 
design modifications by meeting the fol¬ 
lowing subgoals. 

Modularity. The language must make it 
easy for the system designer to create a 
prototype with a high degree of module 
independence and to preserve its good 
modularity properties across many modifi¬ 
cations. Good modularity is essential for 
easy modification. 

An experimental study showed many of 
the problems that arise in modifying soft¬ 
ware result from interactions between 
widely separated pieces of code. 8 Locality 
of information was an important design 
goal of PSDL. The underlying computa¬ 


tional model was chosen to make all inter¬ 
actions between components explicit. This 
model supports a system decomposition 
criterion that combines dataflow and con¬ 
trol flow considerations. 2 

Good modularity means the prototype 
should be realized by a set of independent 
modules with narrow and explicitly speci¬ 
fied interfaces. PSDL supports this con¬ 


cept via operators and data streams. An 
important property of the language is that 
two distinct operators can communicate or 
affect each other’s behavior only by means 
of the data streams explicitly connecting 
them, either directly or indirectly. 

This locality property is important for 
maintenance. It allows the set of modules 
that can potentially interact with a given 
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module to be determined through a simple 
mechanical analysis of the dataflow net¬ 
work. This allows the software tools to 
guarantee that all aspects of a proposed 
change have been covered. The locality 
property also encourages designs contain¬ 
ing an independent component for each 
major design decision. Such designs are 
easier to modify because the information 
required to change a design decision is 
localized in one region of the code. 

The locality property is embodied by the 
PSDL scoping rules and mechanically 
enforced. The implementation of an opera¬ 
tor can only refer to the explicitly declared 
input and output streams of the operator 
and to data streams local to the implemen¬ 
tation of the operator. Implementations of 
operators representing state machines can 
contain closed loops consisting of local 
data streams. 

Simplicity. The language should be 
simple and easy to use. PSDL is simple and 
easy to use because it contains a small 
number of powerful constructs. Designs 
are described in PSDL as networks of 
operators connected by data streams. 

Such networks can be represented as 
dataflow diagrams augmented with timing 
and control constraints. The user interface 
uses the diagrams to provide a convenient 
means for presenting the system structure 
to the designer. The operators in the net¬ 
work can be either functions or state ma¬ 
chines. The data streams can carry excep¬ 
tion conditions or values of arbitrary ab¬ 
stract data types. 

Reuse. The language should be suitable 
for specifying the retrieval of reusable 
modules from a software base. PSDL sup¬ 
ports reusable components with uniform 
specifications suitable for retrieving mod¬ 
ules from a software base. The specifica¬ 
tion part of a PSDL component contains 
several attributes that describe the inter¬ 
face and behavior of the component. These 
attributes help automatically generate a 
uniform specification for the reusable 
component. 9 These uniform specifications 
are used both for retrieval of reusable 
components and for organizing the soft¬ 
ware base. 

Adaptability. The language should sup¬ 
port small modifications to the behavior of 
a module without the need to examine its 
implementation. PSDL supports small 
modifications to modules by means of 
control constraints. We can use control 
constraints to impose preconditions on the 


execution of a module, to add filters to the 
output of a module, to suppress or raise 
exceptions in specified conditions, and to 
control timers. These facilities allow small 
modifications to the behavior of a module 
to be expressed independently of its im¬ 
plementation. 

For example, a common problem dis¬ 
covered in prototype demonstrations is 
that an operator has the intended behavior 
most of the time but not always. The PSDL 
control constraints governing conditional 
execution of operators can help solve the 
problem. We could add a control constraint 
in the form of an input guard predicate, 
where the guard predicate describes the 
circumstances in which the execution of 
the operator will produce the intended 
result and disables the execution of the 
operator in cases where it would not. This 
allows the addition of another operator for 
producing the correct output in the remain¬ 
ing cases, controlled by a complementary 
guard predicate. 

Abstraction. The language should sup¬ 
port a set of abstractions suitable for de¬ 
scribing complex software systems with 
real-time constraints. PSDL provides ab¬ 
stractions suitable for describing large 
systems and real-time constraints. These 
include the nonprocedural control con¬ 
straints mentioned above, timing con¬ 
straints, timers, functional abstractions, 
and data abstractions. 

Examples of timing constraints include 
the maximum execution time, the maxi¬ 
mum response time, and the minimum 
calling period. Timing constraints implic¬ 
itly determine when operators with hard 
real-time constraints will execute. This 
simplifies evolution by removing explicit 
scheduling decisions from the design, thus 
allowing a software tool rather than the 
designer to handle rescheduling caused by 
design changes. 

Requirements tracing. The language 
should support requirements tracing. 
PSDL supports requirements tracing by 
means of a construct for declaring the 
requirements associated with each part of 
the prototype. Requirements tracing is 
important because the prototype must 
adapt to the changing perceptions of the 
requirements resulting from demonstra¬ 
tions of prototype behavior. The links be¬ 
tween each requirement and the parts of 
the prototype realizing the requirement 
determine which parts of the prototype to 
modify when a requirement is changed or 
dropped. 


To prevent the structure of the design 
from being corrupted by multiple modifi¬ 
cations, we must remove parts of the code 
no longer supported by an updated set of 
requirements. This cannot be done safely 
unless the correspondence between the 
requirements and the code is recorded and 
kept up to date. 

The facilities for recording require¬ 
ments trace information in PSDL are used 
by software tools in CAPS to provide auto¬ 
mated aid in maintaining and using this 
information. 

User interface for interactive control 
of prototypes. The user interface aids 
evolution by providing facilities for enter¬ 
ing information about the requirements 
and design, presenting the results of proto¬ 
type execution to the customer, guiding the 
choice of which aspects of the prototype to 
demonstrate, and helping the designer 
propagate the effects of a change. The user 
interface consists of a syntax-directed edi¬ 
tor with graphics capabilities, an expert 
system for communicating with end users, 
a browser, and a debugger. 

The editor enables convenient entry of 
PSDL descriptions into the system while 
preventing syntax errors. It also supports 
displaying graphical summary views of 
the prototype, maintaining the require¬ 
ments trace, and locating parts of the proto¬ 
type design related to particular require¬ 
ments or data streams. 

The expert system provides a paraphras¬ 
ing capability that generates English text 
from PSDL descriptions. This allows end 
users to directly examine the prototype 
without being familiar with PSDL. 

The browser allows the designer to inter¬ 
act with the software database. It has facili¬ 
ties for retrieving and examining reusable 
components stored in the software data¬ 
base system. 

The debugger allows the designer to 
interact with the execution support system. 

It has facilities for initiating execution of 
the prototype, displaying results or trace 
information, and gathering statistics about 
prototype behavior and performance. A 
facility for recording test case coverage 
information helps guide the choice of sce¬ 
narios for a demonstration run. 

The user interface helps the prototype 
design team identify the tasks required to 
update the prototype. The user interface 
maintains the correspondence between 
requirements and parts of the prototype, 
along with lists of unresolved new require¬ 
ments and unresolved modified require¬ 
ments. Whenever a member of the design 
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team is ready for a new task, the system 
presents the lists and lets the designer pick 
an item to resolve. If the designer chooses 
a modified requirement, the interface re¬ 
turns a list of modules previously support¬ 
ing the requirement and lets the designer 
check them off as they are adapted or 
determined to be still valid. 

The effort required for this task coordi¬ 
nation is minimized by presenting the lists 
as menus and allowing the designer to pick 
items using a pointing device. Choosing an 
item results in a summary view of the 
affected modules, which can be browsed 
and updated as required. 

The user interface speeds up the process 
of adapting the prototype by 

(1) helping to coordinate tasks per¬ 
formed by a team of designers, 

(2) helping to focus the designer’s at¬ 
tention on the information relevant 
to a task, 

(3) providing summary views of the 
system or selected components, and 

(4) locating all potentially relevant 
parts of the prototype. 

Software database for managing de¬ 
scriptions and building blocks. The soft¬ 
ware database system consists of a design 
database, a software base, a software de¬ 
sign-management system, and a rewrite 
subsystem. The design database contains 
the PSDL prototype descriptions for each 
software development project using 
CAPS. The software base contains PSDL 
descriptions and code for all available 
reusable software components. The soft¬ 
ware design-management system manages 
and retrieves the versions, refinements, 
and alternatives of the prototypes in the 
design database and the reusable compo¬ 
nents in the software base. The rewrite 
subsystem translates PSDL specifications 
into a normalized form used by the design- 
management system to retrieve reusable 
components from the software base. 9 

The components of the software data¬ 
base actively contribute to the process of 
adapting the prototype to new require¬ 
ments. The software design-management 
system helps maintain the design history 
and locate relevant reusable software 
components. The design history consists 
of the relationship between each version of 
the requirements and the corresponding 
versions of parts of the prototype. This 
information is useful because the customer 
will sometimes retreat to previous versions 
of the requirements. Situations in which 
this might happen include cases where the 


customer gives up on an ambitious require¬ 
ment in response to cost or performance 
estimates resulting from examination of 
the prototype. In such cases, parts of the 
requirements revert to previous configura¬ 
tions. The system helps restore the corre¬ 
sponding parts of the prototype to their 
previous configurations. 

The design database also provides con¬ 
currency control functions that allow mul¬ 
tiple designers to update parts of the proto¬ 
type without unintentional interference. In 
the interest of minimizing delay, the de¬ 
sign database will not lock out read-only 
access to any part of the design, even while 
the design is being updated. Instead, the 
system will allow examination of the pre¬ 
vious version of the component, with a 
warning that a new version is currently in 
preparation. On request, the system will 
provide information about the reason for 
modification of the component (such as a 
new or modified requirement). Enhance¬ 
ments to alternative versions can be ex¬ 
plored in parallel, thus speeding up ex¬ 
ploratory evolution. 

The software base provides reusable 
software components for realizing given 
PSDL specifications. The software base 
speeds up evolution by providing many 
different versions of commonly used 
components, making it easier to try out 
alternative designs. In the PSDL prototyp¬ 
ing method, 2 modules are realized by three 
main mechanisms: 

(1) Retrieval of a suitable component 
from the software base. The software base 
contains generic modules with parameters 
determined as part of the retrieval process. 
It also contains rules for matching a speci¬ 
fication by means of a composite operator 
realized by a network of operators, at least 
one of which must be an available reusable 
component. 9 The retrieval mechanism can 
therefore perform some routine aspects of 
bottom-up design, freeing the designer 
from the need to be familiar with all the 
reusable components in the software base. 

(2) Decomposition of the component 
into a network of simpler components. The 
designer does this if the component cannot 
be retrieved directly from the software 
base and if the component is sufficiently 
complex to benefit from decomposition 
into simpler parts. 

(3) Direct implementation in a program¬ 
ming language. The designer does this if 
the software base does not contain a com¬ 
ponent that performs the required function 
with the required speed. 

The essential problem in the organiza¬ 


tion of object-based databases for manag¬ 
ing reusable components is to allow the 
representation and retrieval of an un¬ 
bounded number of components given 
finite memory and processor speed. We 
must consider an unbounded number of 
components because software designs can 
contain arbitrary user-defined abstract 
data types, and, to be useful, the reusable 
components in the component database 
must be applicable to all of the types in this 
infinite set. 

A practical approach to this problem 
regards the database as containing all the 
components that can be generated from a 
finite set of explicitly stored components 
by finite combinations of a set of primitive 
component constructors. Examples of 
component constructors are transforma¬ 
tions that instantiate generic parameters or 
that create a composite component by 
interconnecting a pair of available compo¬ 
nents. 

Retrievals from such databases will 
generally involve a limited degree of logi¬ 
cal inference, to determine whether a 
component matching the query can be 
constructed from available components 
within a given limited number of construc¬ 
tor applications. Limits are needed to make 
sure retrievals will always terminate. 
These logical inferences are performed 
according to rules stored in the knowledge 
base associated with the component li¬ 
brary. 9 

Execution support for demonstrating 
effects of changes. The PSDL execution 
support system contains a translator, a 
static scheduler, and a dynamic scheduler. 5 
The translator generates code that binds 
together the reusable components ex¬ 
tracted from the software base. Its main 
functions are to implement data streams, 
control constraints, and timers. The static 
scheduler allocates time slots for operators 
with real-time constraints before execu¬ 
tion begins. If the allocation succeeds, all 
operators are guaranteed to meet their 
deadlines even with worst-case execution 
times. As execution proceeds, the dynamic 
scheduler invokes operators without real¬ 
time constraints in the time slots not used 
by operators with real-time constraints. 

The execution support system helps 
speed up design changes by providing a 
localized view of the processes in the 
prototype, analyzing the prototype’s tim¬ 
ing properties, and providing the ability to 
quickly demonstrate the consequences of 
design decisions through prototype execu- 
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Figure 3. Objects and general properties. 


tion. These features are especially impor¬ 
tant for prototyping real-time systems. 

At the programming language level, 
implementations of real-time systems are 
difficult to understand because the instruc¬ 
tions of several logically independent 
processes must often be interleaved to meet 
timing constraints. 10 PSDL presents a view 
to the designer in which logically distinct 
processes are represented as separate inde¬ 
pendent components. The PSDL execution 
support system contains a translator that 
mechanically transforms this independent 
representation into the corresponding pro¬ 
gramming language representation, add¬ 
ing the necessary interleaving in a fashion 
transparent to the designer." 

If the static scheduler succeeds in con¬ 
structing a schedule, the operators in the 
schedule are guaranteed to meet their tim¬ 
ing constraints even under worst-case 
operating conditions. If the static sched¬ 
uler fails to find a valid schedule, it pro¬ 
vides diagnostic information useful for 
determining the cause of the difficulty and 
whether or not the difficulty can be re¬ 
solved by adding more processors. 12 These 
functions are important because the timing 
constraints in complex systems can have 
complicated interactions that are difficult 
to analyze manually. 

Software evolution 
through rapid 
prototyping 

CAPS supports software evolution 
through object-based prototyping and re¬ 
usable software components. Object- 
based prototyping is the rapid construction 
of software systems using objects that 


encapsulate data as building blocks. PSDL 
includes two kinds of objects, correspond¬ 
ing to abstract data types (PSDL types) and 
abstract state machines (PSDL operators). 
Figure 3 shows the general properties of 
the PSDL objects. 

The most important function of objects 
used in prototyping is to localize informa¬ 
tion. This design principle allows us to 
understand, analyze, and execute each 
object independently of other objects, 
reducing the conceptual complexity of the 
prototype system. Since the semantics of 
such objects is independent of the context 
in which they appear, they are likely to be 
reusable. They also provide a convenient 
basis for version control in an evolving 
system. 

Objects can also serve as natural units of 
work in a parallel implementation, since 
they can execute without interfering with 
each other. Parallel implementations are 
attractive in systems with tight real-time 
constraints because multiprocessor sched¬ 
ules exist for many real-time constraints 
that cannot be met on a single processor. 

One of the main difficulties of software 
evolution in traditional contexts is the lack 
of accurate requirements, specifications, 
and design documents. 13 We need precise 
documentation to reliably change the sys¬ 
tem. Especially for older systems, infor¬ 
mation other than the source code is often 
unavailable or obsolete because of the 
large amount of time and effort required to 
manually create and maintain it. 

In PSDL, specifications and justifica¬ 
tion links to the requirements are part of 
the prototype description, and the imple¬ 
mentation descriptions are provided at a 
design level. This information can be sys¬ 
tematically recorded and kept in the tools 
during the prototyping process and auto¬ 
matically supplied by the tools during evo¬ 


lution. In other words, CAPS tools use the 
higher level information to aid the designer 
in modifying the prototype. 

PSDL can describe both the prototype and 
the production versions of the system. A 
PSDL implementation has two parts: a 
skeleton consisting of the modules in the 
system and their interconnections, and a set 
of reusable components containing imple¬ 
mentations of the atomic components in a 
conventional programming language such 
as Ada. The main activities in the system 
implementation phase involve refining par¬ 
tially defined facilities and optimizing im¬ 
plementations. These activities take place at 
both the PSDL level and the programming 
language level. 

Refinements are initially expressed in 
PSDL by (1) adding more constraints to the 
specifications and retrieving new reusable 
components or (2) doing further decomposi¬ 
tions to make the implementation corre¬ 
spond to the refined specification. 

Optimizations are performed at the PSDL 
level by introducing alternative decomposi¬ 
tions that eliminate unnecessary processing 
or allow more efficient algorithms. 

The performance tuning process contin¬ 
ues at the programming language level. 
There, efficient custom implementations for 
operators with tight real-time constraints or 
frequently executed non-time-critical op¬ 
erators are created and added to the software 
base together with corresponding PSDL 
specifications. This process maintains the 
correspondence between the implementa¬ 
tion, design, specifications, and require¬ 
ments. In addition, we can use the same 
tools and techniques to develop the produc¬ 
tion version of the system. 

Changes to the production version of the 
system require changes in the PSDL specifi¬ 
cations. We can meet the changed specifica¬ 
tions by using reusable components from 
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Figure 4. Tool usage in the prototyping cycle. 





(a) 


Figure 5. Regrouping the operators in a 
ture and (b) the regrouped architecture. 


the software base in a flexible manner. 
After the design stabilizes, we can opti¬ 
mize the modified portions of the system. 

Figure 4 summarizes the phases of the 
prototyping cycle where each class of 
CAPS tools is used. 

Designer’s viewpoint. We can classify 
the modifications to a prototype performed 
by a designer as either static changes or 
dynamic changes. Static changes result 





(b) 

i, showing (a) the initial architec- 


from modifying the PSDL source code. 
They are tested by a complete regeneration 
of the executable model of the system. 
Dynamic changes are made using the de¬ 
bugging system during the demonstration 
run of a prototype. They provide immedi¬ 
ate feedback to the customer about the 
effects of proposed alternatives. Both 
static and dynamic changes are necessary 
to effectively carry out the prototyping 
cycle. 


Static changes are done off line, when 
the customer is not waiting and there is 
time for careful design, mechanical check¬ 
ing, scheduling, and translation. There are 
four kinds of static changes: regrouping, 
tuning an object, custom programming, 
and specification changes. 

Regrouping refers to a change that rear¬ 
ranges a set of atomic operators. This kind 
of change localizes information and im¬ 
proves the logical coherence of a design. 
Figure 5 shows an example of this kind of 
change. Figure 5a shows the initial group¬ 
ing, and 5b shows the modified grouping 
for a subsystem. The operators B and D are 
moved into the same subsystem B' because 
both of them use the same input stream a, 
and this stream is not needed in any other 
part of the system. 

Regrouping simplifies the interfaces of 
the major subsystems and makes them 
more coherent. Exploratory prototyping 
often requires this kind of change because, 
in the initial stages, the functions of the 
proposed system are not clear. Once we 
know the parts of the system, the relation¬ 
ships between them become clearer. We 
then want to regroup the parts of the system 
so that related parts appear in the same sub¬ 
systems and higher level groupings corre¬ 
spond to abstractions meaningful to the 
users. 

Another common kind of regrouping 
transformation gathers all of the operators 
that use a state variable into a single state 
machine object, which then hides the state 
variable from the rest of the system. 

Tuning refers to design changes that 
affect the implementation but not the speci¬ 
fication of a composite object. Tuning is 
done at the PSDL level, by supplying an 
alternative decomposition for an object. 
The purpose is usually to simplify the 
implementation or to improve its perform¬ 
ance. Figure 6 illustrates this kind of 
change, where 6a shows the initial decom¬ 
position for a composite object and 6b 
shows a simplified decomposition. 

Custom programming refers to design 
changes that replace part of the implemen¬ 
tation of the prototype system with an 
atomic object implemented directly in the 
programming language. The new atomic 
object produced in this way is added to the 
software base as a reusable component. 
While, in principle, changes in this cate¬ 
gory do not affect the specification of the 
object, in practice they might trigger some 
additional specification changes because 
the new object must fit into the software 
base. 

The specification of the object might 


May 1989 


19 







































Figure 6. Tuning the implementation of an object, showing (a) the initial decom¬ 
position and (b) the simplified decomposition. 


need refining to include additional con¬ 
straints that distinguish it from similar 
objects already in the software base, since 
the specifications of the reusable compo¬ 
nents serve as keys (unique identifiers). 
This kind of refinement is needed if an 
object matching the specification of the 
subsystem is already present in the soft¬ 
ware base, was retrieved at an earlier stage, 
was included in the design, or was found 
lacking in some respect. For example, the 
original reusable component might per¬ 
form the correct function but take too long 
to execute. The additional constraints 
added to the specifications describe the 
performance characteristics that distin¬ 
guish the original implementation from a 
new, optimized implementation. 

Specification changes are needed when 
the customer finds the demonstrated be¬ 
havior of the prototype unacceptable. 
Consequently, the behavior of some ob¬ 
jects in the prototype require adjustment. 
PSDL provides statements for recording 
which requirements justify each attribute 
of an object in the prototype. These links 
can be used in both directions, depending 
on the designer’s working style. For ex¬ 
ample, the designer might be familiar with 
the design of the prototype and thus easily 
able to trace a complaint about an inappro¬ 
priate response to a particular object. The 
system can automatically follow the re¬ 
quirements links to show the list of re¬ 
quirements supported by the offending 
object. The designer can then identify the 
subset of those requirements affected by 
the change, and the system can trace the 
requirements links in the other direction to 


generate a list of objects potentially af¬ 
fected by the change. 

The CAPS system aids the designer in 
propagating the effects of changes by 
maintaining a list of operators potentially 
affected by a change. The system guides 
the designer through the process of review¬ 
ing the operators on the list by presenting a 
task menu. 

A PSDL prototype has a hierarchical 
structure, which shows the decomposition 
of each composite object into more primi¬ 
tive objects. Specification changes must 
maintain the consistency of this hierarchy. 
If the specification of a subcomponent 
changes, the change can affect the specifi¬ 
cation of each composite object containing 
the subcomponent. The CAPS system adds 
all of the ancestors of a modified object in 
the subcomponent hierarchy to the list of 
objects reviewed by the designer. The 
system also has a set of heuristic rules for 
automatically propagating the effects of 
some types of specification changes, in¬ 
cluding changes to the maximum execu¬ 
tion time, maximum response time, mini¬ 
mum calling period, and data types associ¬ 
ated with the input streams and output 
streams of an object. 

An example of automatic constraint 
propagation appears in Figure 7. In this 
example, the maximum execution time of 
the subcomponent B had to increase be¬ 
cause it could not be implemented within 
the originally specified deadline. The 
object B is part of the implementation of 
the composite object A, as shown in Figure 
7c. The operators in the graphical form of 
the implementation are annotated with the 


maximum execution times, and when the 
specification of B changes, the CAPS sys¬ 
tem automatically reflects the change in 
the implementation of a, as shown in Fig¬ 
ure 7d. The constraint associated with 
maximum execution times requires the 
maximum execution time of a composite 
operator not to exceed the sum of the 
maximum execution times along the long¬ 
est path in its dataflow graph. The change 
violates this constraint and causes the 
maximum execution time of the operator A 
to increase, as shown in Figure 7f. 

Another reason for specification 
changes is to increase the probability that 
an object in the software base can be 
reused. A specification change designed to 
improve the reusability of a component 
usually involves a generalization, such as 
introducing some generic parameters for 
the object. This class of changes prevents 
cluttering the software base with large 
numbers of similar objects. 

Dynamic changes are made using the 
debugger as the prototype executes, to 
quickly and roughly test out new ideas 
without going through complete recom¬ 
pilation and rescheduling. A classical 
problem caused by installing patches using 
debuggers is the danger of an undocu¬ 
mented divergence between the execut¬ 
able version of the system and the source 
code. CAPS protects the designer against 
this possibility by maintaining a record of 
the dynamic changes. This record allows 
the original version and each of the alterna¬ 
tives explored in a demonstration run to be 
restored at will during the demonstration. 
It also allows automatic insertion of se¬ 
lected changes into the PSDL source code. 

The set of dynamic changes supported 
by CAPS includes standard debugger func¬ 
tions such as examining and modifying the 
contents of data streams, displaying execu¬ 
tion traces, setting breakpoints, and setting 
conditional data traps. Some less conven¬ 
tional capabilities include controlling the 
real-time clock, selectively disabling some 
threads of a parallel implementation, in¬ 
serting parallel consistency checking op¬ 
erators, modifying triggering conditions of 
operators, and saving execution states so 
that the prototype can be restarted many 
times from the same intermediate point. 

To allow meaningful debugging, the 
deadlines of the time-critical operators 
have to be set back by the skew time , which 
equals the time spent in the debugger plus 
the amount of time required to restore the 
execution state and resume execution. The 
execution support system dynamically 
monitors the execution of the prototype 
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OPERATOR B INPUT x: real OUTPUT y: real 
MAXIMUM EXECUTION TIME 25 ms 
END 
(a) 


35 40 


(d) 


OPERATOR B INPUT x: real OUTPUT y: real 
MAXIMUM EXECUTION TIME 35 ms 
END 

(b) 


OPERATOR A INPUT x: real OUTPUT z: real 
MAXIMUM EXECUTION TIME 65 ms 
END 
(e) 


25 40 


(c) 


OPERATOR A INPUT x: real OUTPUT z: real 
MAXIMUM EXECUTION TIME 75 ms 
END 

(f) 


Figure 7. Automatic constraint propagation, showing (a) the original subcomponent specification, (b) the modified subcompo¬ 
nent specification, (c) the original supercomponent implementation, (d) the modified supercomponent implementation, (e) the 
original supercomponent specification, and (f) the modified supercomponent specification. 


(b) 

maximum_execution_time( A)=10 
maximum_execution_time(B)=20 
s=skew time 

e=excess execution time for A 


Figure 8. Debugging a real-time prototype, (a) Scheduled execution, (b) Actual 
execution. 
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and automatically traps to the debugger I 

when a time-critical operator misses its 
deadline. At that point the designer can 
examine the state of the system to see if 
there is something wrong. The designer 
has the option of (1) resetting the real-time 
clock to give the operator some extra CPU 
time before its deadline arrives, (2) allow- (a) 

ing it to exceed its deadline by a specified 
amount, or (3) abandoning execution. 

Consider the example in Figure 8. In the 
example, the execution of operator A has 
exceeded its allotted time and control has 
passed to the debugger. If the designer 
chooses to allow A to pass its deadline and 
complete execution, then operator B will 
be delayed by the excess execution time e 
and will have that much less time to com¬ 
plete before its time slot runs out at time 
130+s. Such an experiment will help deter¬ 
mine whether the circumstances that cause 
A to exceed its deadline allow B to finish 
earlier to compensate. If the designer had 
decided to reset the real-time clock in¬ 
stead, the operator A would have gotten 
some invisible extra time, so B would still 
have a full 20 time units to meet its dead¬ 
line after A completed execution. 

Selectively disabling some threads of a 
parallel program helps get the maximum 
possible information out of a demonstra¬ 
tion run. Figure 9 shows an example of this 
situation. Suppose that the output stream c 
from operator A is hopelessly in error and 
that a data trap has detected the problem 
and passed control to the debugger. If the 
designer is unable or unwilling to substi- 



Figure 9. Disabling a parallel thread. 


May 1989 


21 



















.Component. 


Atomic' 

type 


‘ Composite 
type 


Atomic 

operator 


‘Composite 

operator 


Figure 10. Class structure for prototype components. 


CLASS Component 
SUPERCLASSES( ) 

ATTRIBUTES 
name: string 
generic: set [parameter] 
description: string 
support: set[requirement] 

END Component 

CLASS Operator 
SUPERCLASSES [Component] 
ATTRIBUTES 

input, output, states: set[parameter] 
max_exec_time, max_resp_time, 
min_call_period, period, 
finish_within: time 
spec: assertion 
END 

CLASS AtomicOperator 
SUPERCLASSES [Operator] 
ATTRIBUTES 
language, code: string 
END 

CLASS CompositeOperator 
SUPERCLASSES [Operator] 
ATTRIBUTES 
dfd: graph 

constraints: set[control_constraint] 
END 


Figure 11. Attributes of prototype 
components. 


tute a correct value for c, he or she can 
temporarily disable the execution of C and 
restart the system to see the results of 
executing B and D using the value of b, 
which was not affected by the fault in A. 
This is equivalent to removing a faulty data 


value from the data stream c and will not 
cause any further faults if operator E is 
triggered by the arrival of new input data. 
If E is triggered by a temporal event, then 
disabling C might cause another fault if E 
requires a fresh value of e every time it 
executes. 

Consistency checking, as performed by 
dynamically inserted data traps, must not 
interfere with the timing properties of 
normal prototype execution. In a single¬ 
processor implementation this requires 
stopping the real-time clock while the con¬ 
sistency checks are performed. In multi¬ 
processor implementations such consis¬ 
tency checks can be performed in real time 
if enough processors are available and if 
the consistency checks are shorter than the 
primary computations. 

Tool viewpoint. The tools in CAPS are 
organized around an object-oriented data¬ 
base management system used to realize 
the design database and the software 
base. 14 The components of a prototype de¬ 
scription are instances of the subclass hier¬ 
archy shown in Figure 10. Selected attrib¬ 
utes of a representative subset of these 
object classes appear in Figure 11. 

To effectively support modifications, 
the tools in CAPS must address several 
consistency problems. Some of the prob¬ 
lems of consistency with respect to the 
subcomponent hierarchy were discussed 
in the previous section. Another problem is 
maintaining consistency between the gra¬ 
phical and textual views of a prototype. 

Graphical views arise as part of the 
implementation of a composite object, 
while text views arise for the specification 
parts of the immediate components of a 
composite object. The graphical view and 
the textual view contain different forms of 
the same information, so when the de¬ 
signer changes one view, the other one 
must be automatically updated to maintain 
consistency. This process requires some 


care, since each view contains information 
not visible in the other view. Different 
strategies are appropriate for each. 

If a new operator is added in the graphi¬ 
cal view, it will lack information such as 
control constraints and the types of the 
values on its input and output streams. 
Since control constraints are optional, that 
part of the text view can be left empty. 
Since the data types of streams are not 
optional and an accurate value is not avail¬ 
able, the corresponding slot in the textual 
view must be filled by a completion term. 
A completion term is a special value recog¬ 
nized by the syntax-directed editor as a 
placeholder for a missing part of the proto¬ 
type. Its distinctive display reminds the 
designer that more information must be 
supplied before the prototype can execute. 

If a new operator is added in the text 
view, it will lack information about the 
position of the corresponding icon in the 
graphical view. Since an icon cannot be 
displayed without choosing a particular 
position, a heuristic generates a default po¬ 
sition. 

One method for doing this is to put the 
new icon at the center of gravity of the 
sources and destinations of all the inputs 
and outputs of the new operator. Next, cut 
the old display into two parts with a hori¬ 
zontal line through the position of the new 
icon, moving the old icons outward until 
the new icon has a minimum clearance 
from all the old ones. Then reconnect the 
broken arrows. Finally, do the same with a 
vertical line through the position of the 
new icon. 

Figure 12 illustrates this process. Figure 
12a shows the old text view, 12b shows the 
new text view, 12c shows the old graphical 
view with the default position and vertical 
expansion axis, and 12d shows the new 
graphical view. This heuristic has a global 
effect, since potentially it can transform 
the layouts of all the objects in the graphi¬ 
cal view. 


22 


COMPUTER 







OPERATOR A INPUT x,s:t OUTPUT y:t END 
OPERATOR B INPUT y:t OUTPUT z,s:t END 

(a) 

OPERATOR A INPUT x,s:t OUTPUT yl:t END 
OPERATOR B INPUT y2:t OUTPUT z,s:t END 
OPERATOR C INPUT yl:t OUTPUT y2:t END 

(b) 






x 


I Center of gravity 


(d) 


Figure 12. Consistency between text and graphical views, showing (a) the initial 
text view, (b) the modified text view, (c) the initial graphical view, and (d) the 
modified graphical view. 


A change to the specification of an op¬ 
erator invalidates its implementation. Such 
changes signal the project database man¬ 
agement system to save the previous ver¬ 
sion of the operator. This prevents losing 
the results of previous efforts should the 
designer later want to restore the previous 
version. The tree of suboperators rooted at 
the modified operator is then removed 
from the new version of the prototype, and 
the software base is searched for an im¬ 
plementation of the new specifications. 
Since the operators containing the modi¬ 
fied operator are invalidated by such a 
change, the system adds them to a list of 
action items for the designer. 

Evolution of a 
hyperthermia system 

To illustrate some typical prototype 
modifications, this section discusses part 
of the prototyping cycle for a hyperthermia 
system. The hyperthermia system treats 
brain tumors by using microwaves to heat 
the affected area to a temperature that will 
kill tumors but not normal tissue. An 


embedded software system controls the 
microwave power based on feedback from 
a temperature sensor inserted into the pa¬ 
tient’s brain. The goals of the prototyping 
effort are to evaluate the safety of the 
proposed system and to establish the feasi¬ 
bility of implementing the required control 
functions. 

The initial PSDL specification for the 
top level of this system appears in Figure 
13. The details of a PSDL decomposition 
for the initial version of this prototype can 
be found elsewhere, 7 so I will not repeat 
them here, although the information they 
contain is necessary to make the prototype 
executable. I have provided informal de¬ 
scriptions of lower level details as needed 
to explain the effects of the proposed 
modifications. The second-level decom¬ 
position of the brain tumor treatment sys¬ 
tem contains a simulated patient and the 
proposed software system for controlling 
the microwave power level. 

Demonstration of the initial version of 
the prototype led to a question about the 
safety of the proposed system. In the initial 
version of the prototype design, informa¬ 
tion about the size of the tumor was ex¬ 
tracted from the patient chart using an 


operation of the abstract data type 
medicalJiistory called getJumordia¬ 
meter. This information determines the 
initial microwave power level. The 
get tumor diameter operation raises an 
exception called no-tumor if the patient’s 
chart does not contain a description of a 
tumor in the patient’s brain. The response 
to the exception in the initial version of the 
prototype sets the microwave power level 
to zero and issues an immediate 
treatmentJinished signal, which is plau¬ 
sible given the initial system interface 
specified in Figure 13. However, when this 
behavior was demonstrated, the potential 
users of the system pointed out that such a 
response can hardly be considered safe. If 
a healthy patient was mistakenly sent for 
hyperthermia treatment, the system would 
produce a response indicating something 
was wrong (an early treatment-finished 
signal) only after the start treatment 
switch was pressed, which happens only 
after the temperature probe has been in¬ 
serted into the patient’s brain. A safe de¬ 
sign should prevent such a dangerous pro¬ 
cedure if not medically necessary. 

Figure 14 shows a PSDL specification 
of the revised top level of the prototype, 
and Figure 15 shows the corresponding 
implementation. A new layer has been 
introduced because the safety question has 
changed the boundaries of the system to 
include the central hospital database. This 
change addresses the issue of how the 
patient is identified to the brain tumor 
treatment system. 

The original version of the brain tumor 
treatment system has been included as a 
subsystem, as shown in Figure 15. This 
change minimizes the effects on the previ¬ 
ously developed prototype and allows a 
quick demonstration to validate the newly 
proposed interface. However, it leaves 
some dead code in the original design, 
since the patient charts entering the brain 
tumor treatment system are now guaran¬ 
teed to contain the description of a brain 
tumor. 

In preparation for further refinements, 
the prototype design is cleaned up after the 
initial demonstration, as shown in Figure 
16. Note that the specification part of the 
top level is not affected by the change. The 
new version reflects the restriction men¬ 
tioned above, which has been used to 
tighten up the design by keeping unneces¬ 
sary information out of the brain tumor 
treatment system (the system does not use 
information in the patient’s chart other 
than the tumor’s diameter). 

The change affects the interface of both 
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OPERATOR brain_tumor_treatment_system 
SPECIFICATION 

INPUT patient_chart: medical_history, 
treatment_switch: boolean 
OUTPUT treatment_finished: boolean 
STATES temperature: real 
INITIALLY 37.0 
DESCRIPTION 

{ The brain tumor treatment system kills tumor cells 
by means of hyperthermia induced by microwaves. 

) 

END 


OPERATOR hospital_system 
SPECIFICATION 
INPUT patient_id: string, 

treatments witch: boolean 
OUTPUT treatment_finished: boolean, 
tumorjocationi string 
DESCRIPTION 

{ The hospital system provides hyperthermia treatment 
for brain tumors. 

} 

END 


Figure 13. Initial top-level specification. Figure 14. Revised top-level specification. 


the hospital database and the brain tumor 
treatment system. It also ripples through 
the lower levels of the system, resulting in 
the removal from the brain tumor treat¬ 
ment system of the medical history type, 
the nojumor exception, and the associ¬ 
ated exception handlers. 

Such simplifications help keep future 
modifications easy to make and prevent 
remnants of abandoned alternatives from 
contaminating the design of the production 


version of the system. They often improve 
the performance of the system as well. The 
CAPS designers are exploring the feasibil¬ 
ity of providing high-level editing com¬ 
mands for reducing the designer effort 
needed for such simplifications. 

T he effort required for evolution of 
a software system can be reduced 
through prototyping. Prototyping 
can stabilize the requirements for both new 


systems and proposed enhancements to ex¬ 
isting systems. Feedback from demonstra¬ 
tions of proposed system behavior is es¬ 
sential for effectively validating complex 
requirements, such as those for large or 
embedded real-time systems. The cus¬ 
tomer and the developer must examine a 
series of changes to proposed system be¬ 
havior and perceived requirements to reach 
a common understanding. It costs less to 
use a prototype than production-quality 
code to support this process because proto¬ 
types are simpler and easier to modify than 
production-quality implementations. 

The effectiveness of prototyping is lim¬ 
ited if carried out manually. A high-level 
language, a systematic prototyping 
method, and an integrated set of computer- 
aided prototyping tools are important for 
realizing the potential benefits of prototyp¬ 
ing. Simplicity was the primary goal in 
designing the Computer-Aided Prototyp¬ 
ing System, since the feasibility and effi¬ 
ciency of rapid prototyping depend on 
simplifying the tasks of the software engi¬ 
neer. 

Prototyping is also aided by a powerful 
set of abstractions appropriate for a prob¬ 
lem domain, especially if these abstrac¬ 
tions are embodied in a set of reusable 
software components that can be automati¬ 
cally retrieved based on specifications of 
the desired behavior. We can save effort in 
the long run by building up a comprehen¬ 
sive library of such components for an 
application area if more than one software 
system must be developed for the same 
problem domain. An essential part of any 
practical computer-aided prototyping en¬ 
vironment is a design database that main¬ 
tains the hierarchical structure of a proto¬ 
type and the relationships between mul- 
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DATA STREAM patient_chart: medical_history 

CONTROL CONSTRAINTS 
OPERATOR brain_tumor_treatment_system 
TRIGGERED BY ALL treatment_switch, patient_chart 

END 


Figure IS. PSDL implementation of the revised top level. 
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DATA STREAM tumor_diameter: real 

CONTROL CONSTRAINTS 
OPERATOR brain_tumor_treatment_system 

TRIGGERED BY ALL treatments witch, tumor_diameter 

END 


Figure 16. Cleaned-up implementation. 


tiple versions developed during prototyp¬ 
ing. An advanced design database should 
automatically propagate consequences of 
decisions made by a designer. 

A group of people must work concur¬ 
rently to evolve a typical software system 
within practical time schedules. We need 
better automatic methods and tools for 
coordinating the efforts of many people 
working on the same software system. 
Automatic means for combining compo¬ 
nents designed by different people and 
detecting potential conflicts would help to 
solve this problem. When coupled with a 
means for producing sets of alternative 
components compatible in all combina¬ 
tions, such tools would enable rapid tailor¬ 
ing of a prototype to match a user’s needs. 

In the future, systems will be maintained 
using prototype descriptions as the pri¬ 
mary representation. To automatically 
generate production code, these represen¬ 
tations will be augmented with descrip¬ 
tions of expected operating loads, environ¬ 
mental characteristics, optimization crite¬ 
ria, and design advice. This will preserve 
flexibility and enable global optimiza¬ 
tions, which might block further evolution 
of the system if applied manually. □ 
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An Object-Oriented VLSI 
CAD Framework 

A Case Study in Rapid Prototyping 


Rajiv Gupta, Wesley H. Cheng, Rajesh Gupta, Ido Hardonag, and Melvin A. Breuer 
University of Southern California 


Example is more efficacious than precept. 

— Samuel Johnson 

P erhaps the most difficult part of 
constructing a large software sys¬ 
tem is deciding exactly what to 
construct. Requirements analysis, as soft¬ 
ware engineers call it, is the most crucial 
phase in the life of a project. An error in 
this phase can not only add to the time 
required for completing the project, but 
also lead to a delayed product that was not 
required in the first place. 1 

The difficulty arises from two sources. 
Typically, the would-be users do not quite 
know what they want, at least not until they 
have tried out some version of the pro¬ 
gram. Compounding this difficulty is the 
fact that the planner of any software design 
activity does not have an exhaustive reper¬ 
toire of questions that will yield him the 
necessary information. Neither can he be 
sure that the specifications he has derived 
are complete; chances are, they are not. 
Rapid prototyping has been touted as a way 
out of this deadlock. 2 

For any software effort with more than a 
few thousand lines of code, some form of 
prototyping is a must. As noted by Brooks, 
“The management question, therefore, is 
not whether to build a pilot system and 
throw it away. You will do that. The only 
question is whether to plan in advance to 
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Object-oriented 
database management 
systems eminently 
support rapid 
prototyping, letting 
programmers gradually 
refine a subset of objects 
and operations instead 
of specifying and 
developing a complete 
application. 


build a throwaway, or to promise to deliver 
the throwaway to customers.” 3 The incep¬ 
tion of the National Test Facility, with its 
explicit charter to build a national testbed 
for prototyping and simulating Strategic 
Defense Initiative command, control, and 
communications (C 3 ) software and other 
battle management software, indicates the 
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growing recognition and importance of 
rapid prototyping as a critical part of soft¬ 
ware development. 

Some researchers claim that object-ori¬ 
ented programming in general, and object- 
oriented database management systems 
(OODBMSs) in particular, 4 ’ 9 offer several 
features that promote rapid prototyping. In 
this article, we study the suitability of 
OODBMS concepts for rapid prototyping 
in the realm of VLSI computer-aided de¬ 
sign systems. CAD systems typically in¬ 
volve much user interaction. Hence the de¬ 
velopment of CAD software benefits 
greatly from user feedback, making rapid 
prototyping a desirable approach. 

This article illustrates, with the help of 
an actual prototype VLSI CAD framework 
called Cbase, 10 how concepts such as data 
abstraction, property and operation inheri¬ 
tance, object specialization/generaliza¬ 
tion, data hiding, method/trigger combina¬ 
tion, code reusability, and polymorphism 
offered by OODBMSs support rapid proto¬ 
typing. We conducted our work on Vbase, 
a commercially available OODBMS from 
Ontologic, but the results and conclusions 
apply to any database with comparable 
capabilities. To implement the prototype 
user interface, we used the XI1 toolkit, a 
windowing package from the Massachu¬ 
setts Institute of Technology that is also 
built around the object paradigm. 
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Rapid prototyping: 
the basics 

Despite progress in prototyping tools, 
the basic steps involved in rapid prototyp¬ 
ing have not changed. The programmer 
implements the key portions of a large 
application that provide basic system func¬ 
tionality, along with sample interfaces. 
The user “test drives” and critiques the 
prototype. The recommendations are in¬ 
corporated, and these two steps are iter¬ 
ated. In this manner, the prototype evolves 
gradually. If the performance is satisfac¬ 
tory at each stage, and no major design 
changes are warranted, development con¬ 
tinues. Otherwise the prototype is aban¬ 
doned, although it might serve as an ex¬ 
ecutable specification for future versions. 2 

This approach to large software devel¬ 
opment has several advantages, not the 
least of which is the early involvement of 
users." While software developers like to 
design software with respect to a set of 
formal specifications, users evaluate it 
against actual functional requirements. 
Early, realistic validation by the user can 
prevent a lot of rework and redesign. In 
addition, less obvious effects and prob¬ 
lems often surface during prototyping, and 
several prototypes can be tried. Most im¬ 
portant, however, is rapid prototyping’s 
accommodation of the stream of changes 
requested by the users once they have seen 
a working version of the program (i.e., it 
supports time-varying specifications). 

A programming environment that pro¬ 
motes rapid prototyping must provide 
powerful data modeling features to ensure 
the fidelity of the prototype. Substantial 
savings in modeling and programming 
time can accrue if the data model mimics 
the real-world objects. The environment 
should encourage gradual evolution so that 
the prototyping phase can begin without a 
detailed formal specification of the sys¬ 
tem. Also, since a prototype is only a par¬ 
tial system, the programmer should be able 
to assign default behaviorsto each object. 
For example, a system might start with a 
very simple display routine for all the ob¬ 
jects. Once a first-cut user interface has 
been developed, the environment should 
let the programmer make it more sophisti¬ 
cated by implementing specialized display 
procedures for each object type. In addi¬ 
tion, the environment should encourage 
code reusability, to extract maximum work 
from a minimum of code, and generic 
programming, to avoid reprogramming as 
the system evolves. 


The tools and 
environment 

Cbase 10 is an object-oriented framework 
for computer-aided VLSI circuit design. It 
provides a common repository of both cir¬ 
cuit objects and their associated opera¬ 
tions, a tool interface for writing new 
applications, an object bag that holds any 
type of object for ease of reference, and a 
user interface for invoking applications or 
viewing objects in the database. Cbase 
provides a platform for creating, display¬ 
ing, manipulating, and maintaining large 
digital designs. 

Cbase uses Vbase 5 as the object man¬ 
ager and the XI1 toolkit for graphics and 
window management. Both packages offer 
several up-to-date features that have 
evolved from such diverse disciplines as 
artificial intelligence, programming lan¬ 
guages, compiler theory, and database 
theory. 

Vbase provides a type definition lan¬ 
guage (TDL) for object schema definition, 
and a C object processor (COP) for object 
manipulation. A programmer can use a 
TDL to specify types of complex objects, 
their properties and interrelationships, and 
associated operations. The object type 
definitions can be arranged in a type hier¬ 
archy that determines property and opera¬ 
tion inheritance among them. Only single 
inheritance is currently supported. The 
TDL compiler compiles the user-defined 
types into the database, where they supple¬ 
ment the system-defined types. 

COP is an object-oriented extension to C 
that provides constructs for accessing and 
manipulating objects. Several specialized 
constructs are also provided, such as those 
for iterating over aggregates or collections 
and those for handling exceptions. Perhaps 
most significant is COP’s mapping of data¬ 
base objects into the C process space. Once 
the database is opened, database objects 
can be accessed in much the same way as C 
variables, and they observe all the conven¬ 
tions followed by C variables. This frees 
the programmer from the chores associ¬ 
ated with bringing objects to and from 
disk. Vbase also provides a source-level 
debugger, an object browser, and Object 
SQL for querying the database. 

With the advent of multiwindow sys¬ 
tems built on a bitmapped display, users 
expect much more from a user interface 
than they did when only CRTs were avail¬ 
able. A good user interface is generally 
time-consuming to build because it has to 
deal with low-level tasks such as I/O, as 


well as provide such constructs as pull¬ 
down menus, pop-up dialog boxes, and 
mouse-pointing capabilities. Program¬ 
ming all this from scratch requires a sub¬ 
stantial amount of design, coding, and 
debugging. 

The Cbase user interface is implemented 
using the XI1 toolkit package, which is 
available as a library of standard C subrou¬ 
tines. The X toolkit provides predefined 
widgets (window objects) that a program¬ 
mer has only to instantiate and organize 
once he or she has decided on the look and 
feel of the user interface. Our system uses 
primitive X operations for graphics opera¬ 
tions such as drawing buses and ports. (We 
do not necessarily advocate Vbase or XI1 
in CAD software development. The con¬ 
cepts discussed in this article are true of 
any software development using the ob¬ 
ject-oriented paradigm.) 

Evolution of Cbase 

Cbase grew out of the need for a com¬ 
mon platform for integrating various CAD 
applications under development at the 
University of Southern California. The 
initial requirements called for a persistent 
data structure versatile enough for most 
CAD applications. In addition, the system 
had to allow different applications to work 
on and update the same circuit design. 

The development of Cbase took place 
through the construction of two successive 
prototypes, Cbase 1.0 and Cbase 2.0. When 
the first version of Cbase was reviewed by 
the “customer,” it not only successfully 
demonstrated the feasibility of the project 
goals, but also led to a review of the origi¬ 
nal goals, based on the programming 
team’s experience with the first working 
prototype. The resulting specifications for 
Cbase 2.0 were better defined, and the 
corresponding system became much more 
powerful than originally envisioned. 

We conceived Cbase 1.0 as a layered 
structure, whose layers would evolve as 
more functionality was added to it. Figure 
1 shows the organization of various layers 
and the languages/packages upon which 
they were implemented. Cbase 2.0 uses the 
same organization. It is a tribute to the 
object paradigm that the same basic or¬ 
ganization can support the increased com¬ 
plexity and extra functionality of Cbase 
2.0 over Cbase 1.0. 

Core (CAD Object Repository), the 
innermost layer of Cbase, consists of 
schema or type definitions for circuit ele¬ 
ments. The object schema has been defined 
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X, COR Prolog, Lisp, etc. 



Figure 1. Layered organization of Figure 2. Cbase 1.0 is-a hierarchy. 

Chase. 


□ 



in Vbase’s TDL. Cbase 1.0 implemented 
the is-a hierarchy shown in Figure 2. We 
used a very simple but extensible model of 
circuits in this version. The basic object 
types employed in modeling a circuit were 
cells, ports, and buses. Bus was further 
specialized into net, with bit-width con¬ 
strained to 1, and port was specialized into 


terminal, with bit-width 1. The topology of 
the circuit was represented by dynamic 
links between these objects, which were 
stored as properties of the corresponding 
objects. Each cell could be associated with 
several I/O ports, and each port could be 
connected to a bus (or wire). Cells could 
also be organized hierarchically. 


In Cbase 2.0, we have considerably 
enhanced the Core layer and introduced 
several specialized refinements of the cell 
object type, such as register, adder, and 
multiplexer. Figure 3 shows the Cbase 2.0 
type hierarchy. 

More (Method Object Repository) is a 
collection of methods associated with cir- 
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cuit object types. It insulates the applica¬ 
tion developer from internal changes in 
Core through an OODBMS-supported 
mechanism called polymorphism. Meth¬ 
ods in More are written in COP, and meth¬ 
ods for creating, deleting, and maintaining 
the object types in the Core have been 
implemented. The primary difference be¬ 
tween Cbase 1.0 and 2.0 is the addition of 
methods catering to the new object types. 

The Cbase tool interface is a library of 
object-independent access/maintenance 
routines that define the protocol through 
which all the applications access the data¬ 
base. While methods in More are tightly 
bound to the objects in Core, no such re¬ 
striction is placed on the operations de¬ 
fined in the tool interface. The Cbase 1.0 


tool interface was virtually nonexistent, as 
that version was designed to develop work¬ 
ing prototypes, not new applications. 

The Cbase 2.0 tool interface has proce¬ 
dures that application programs and the 
user interface can use to manipulate circuit 
objects in a generic, type-independent 
manner. It uses a file-based protocol to 
communicate with applications written in 
alien languages such as Lisp. For example, 
using the tool interface, applications can 
request Cbase to highlight certain circuit 
objects on the graphic display, as shown in 
Figure 4. The tool interface also contains 
procedures for exporting and importing 
circuits to and from files. 

The most visible enhancement to Cbase 
2.0 is in the user interface. To access cir- 


1 subsystems in the 
database, Cbase 1.0 had a multiwindow 
user interface based on the X10 window¬ 
ing package. Access to several utilities, 
such as the Vbase Object Browser, Object 
SQL, Unix operations, and primitive help 
features, was built into the interface. Cbase 
2.0 adds a structural view editor so that a 
user can interactively create and manipu¬ 
late circuits in the database by working 
with a schematic display. All circuit ob¬ 
jects have been given image properties, 
and data entry forms have been added so 
that nongraphic properties of objects can 
be displayed and edited. A user can work 
with a hierarchical circuit by moving up 
and down the hierarchy. The Cbase 2.0 
user interface provides a convenient sche- 
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define Type Cell 


hasPorts: distributed SetfPort] 
inverse $Port$isOnCell; 


end Cell; 
define Type Port 


isOnCell: distributed Set[Cell] 
inverse $Cell$hasPorts; 


end Cell; 


Figure 5. TDL segments showing 
many-to-many relationship between 
cell and port. 


matic capture facility and has hooks for 
further enhancements. 

The main purpose of Cbase is to provide 
a framework for integrating diverse VLSI 
CAD applications. Cbase 1.0 supported 
three CAD applications. Since these sys¬ 
tems primarily used files for I/O, a file- 
based interface was used. These applica¬ 
tions migrated directly to Cbase 2.0 with 
little change. Currently, several applica¬ 
tions that work directly off the database are 
being developed. 

Several features of Cbase’s evolution 
are noteworthy. A working version was 
available at all times during the develop¬ 
ment of both prototypes, allowing en¬ 
hancements to be added incrementally. 
Instead of starting with a formal require¬ 
ment specification document, specifica¬ 
tion was an ongoing process. 

OODBMS features that 
aid rapid prototyping 

Several OODBMS features helped us 
build the Cbase prototype. In this section 
we illustrate each OODBMS concept with 
examples from our code and show how the 
feature’s absence would have resulted in 
more design effort, more code, or both. 

Modeling power. One of the major 
advantages of the object-oriented para¬ 
digm is increased modeling power. The 
objects and their interrelationships in 
OODBMSs can be aligned very closely to 


the real-world objects and their interrela¬ 
tionships. On the other hand, conventional 
data modeling paradigms such as file for¬ 
mats or relational data models require 
considerable effort to force real-world 
objects into fixed programming con¬ 
structs. Thus, a semantic gap exists be¬ 
tween the way information is stored and 
the way it will be used. Relational data¬ 
bases, in particular, are inadequate for 
storing complex information structures 
such as those in CAD. 12 

Consider, for example, the task of mod¬ 
eling many-to-many relationships. To 
make the example concrete, consider cell 
and port object types. In general, a cell can 
have many ports, and a port can be on many 
cells. (In Cbase 1.0, a port can be shared 
between a cell and its subcell.) The TDL 
segments in Figure 5 show the relevant 
parts of the definitions of the port and cell 
object types. The inverse clause helps 
maintain the two-way pointers between 
ports and cells. Thus, the insertion 

$Set$Insert(aPort, aCell.hasPorts) 

where aPort and aCell are port and cell 
objects respectively, would include aPort 
in the set aCell.hasPorts, and aCell in the 
set aPort.isOnCell. In the relational model, 
the port and cell definitions would roughly 
correspond to a relation for each. How¬ 
ever, to model this relationship, a program¬ 
mer would have to introduce an extra rela¬ 
tion (or an intersection record). Further¬ 
more, a join over these relations might be 
required to retrieve combined information. 
The gain in both modeling power and ob¬ 
ject access time in the case of OODBMSs 
is substantial. 

OODBMSs typically provide a set of 
predefined system types, such as set, 
queue, stack, list, and ordered dictionary. 
Vbase provides many of the routinely used 
data structures and their associated opera¬ 
tions, such as insert, push, and pop. This 
simplifies the modeling effort, as the de¬ 
signer can concentrate on the problem at 
hand and not clutter the solution with data- 
structure-specific routines. 

Another advantage of storing a powerful 
data structure directly on the disk is that 
most applications do not need a local, 
memory-resident data structure. When 
accessed, the relevant information about 
an object is automatically cached into 
memory. No code for loading and mapping 
disk information to memory data struc¬ 
tures is needed. If the same information 
were stored using a file format such as 
EDIF (Electronic Design Interchange For¬ 


mat), the front end of every application 
would have to be a parser/loader utility. 
Note that this advantage does not apply to 
object-oriented languages that lack object 
persistence, such as C++, SmallTalk, and 
Objective-C. 

To clarify this point, consider the task of 
drawing a circuit consisting of cells, ports, 
and buses. A programmer need only iterate 
over those circuit objects in the database 
and draw each one of them. This is exactly 
how one would like to think of drawing a 
circuit, that is, without building a set of 
queries to extract the data from the data¬ 
base, loading them into local data struc¬ 
tures, and then displaying them. 

Object specialization!generalization, 
classification, and aggregation. Using a 
limited set of constructs to model several 
concepts inevitably leads to a loss of exact 
meaning. OODBMSs provide several 
mechanisms to model different relation¬ 
ships among objects. 

Object specialization!generalization 
refers to the ability to organize objects in 
an is-a hierarchy. For example, in Cbase, 
register is a cell, which in turn is a 
CktBaseType, which is an entity (see Fig¬ 
ure 3). 

Classification is the ability to relate an 
object to a group of objects via the is- 
instance-of relationship. To check the class 
(or type) to which an object O belongs, one 
simply checks O.DirectType. The function 
TypeOffO) (which is defined on entity, 
and hence inherited by every object) also 
returns the type of object O. 

Aggregation allows the programmer to 
model an object as an aggregate of its 
constituent objects. This type of relation¬ 
ship is known as the is-part-of relationship 
and is specified in TDL by defining an 
object’s properties. For example, the con¬ 
stituent objects in a cell are given in the 
properties clause of the cell TDL, as shown 
in Figure 6. 

Research in artificial intelligence and 
semantic data modeling has shown that 
these three relationship classes are suffi¬ 
cient to model many real-world situations. 5 
Also, the ability to represent different rela¬ 
tionships directly without overloading any 
single construct (as must be done in con¬ 
ventional models due to the small set of 
fixed types of a particular language) leads 
to a clearer model and cleaner code. This, 
in turn, helps rapid prototyping by reduc¬ 
ing development time. 

Data abstraction and data hiding. The 
advent of third-generation programming 
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languages (such as CLU) pointed out the 
need for a clear distinction between the 
storage structures associated with data and 
the logical structure of the information. 
Data abstraction refers to the extreme case 
of this separation, where the only access to 
the storage structure is through a set of 
predefined operations. TDL defines a set 
of operations for each VLSI object in 
Cbase. Data hiding insulates the program¬ 
mer from the actual structure in which the 
data are stored. 

For example, the cell definition in Fig¬ 
ure 7 lists some of the allowable operations 
on a cell — delete, CreDrawEdit, Display- 
Form, etc. 

Even conventional programming lan¬ 
guages promote data abstraction and data 
hiding as good programming practices 
through defining record types, giving 
meaningful names to variables, and writ¬ 
ing routines to manipulate fields in a rec¬ 
ord. But there is no way to enforce these 
practices in conventional languages. In 
OODBMSs, completely encapsulating an 
object with its data and operations forces 
the programmer to use the correct opera¬ 
tions on all objects. In addition, a program¬ 
mer needs only to know about the objects 
that his or her code uses. 

Interface modeling. We also found the 
object paradigm useful in modeling the 
Cbase user interface. Building the inter¬ 
face was a simple task of using the prede¬ 
fined widgets in the XI1 toolkit. Program¬ 
ming with widgets consisted mainly of 
declaring several types of widgets (such as 
label widget and command widget), at¬ 
taching them to an appropriate parent 
widget, setting the size and position of the 
windows, and linking the routine that 
should be invoked (the call-back routine) 
when a particular widget is selected. Dy¬ 
namic creation or destruction of a widget is 
performed with a single call to the create/ 
destroy procedures. The toolkit provides 
mouse-pointing facilities, text widgets 
with editing functions based on the Emacs 
text editor, and several other features that 
make implementing a user interface easier. 

We saved considerable time when we 
switched from usipg X10 primitive calls in 
the library of C calls to the toolkit in XI1. 
Even the simple user interface in Cbase 1.0 
(which used X10) required a lot of design 
and coding. Cbase 2.0 used primitive X 
calls only for the graphics portion, which 
required interactive drawing and modifi¬ 
cation of objects on the screen. The rest of 
the user interface consisted of toolkit 
commands. We easily implemented com¬ 


posite objects such as pull-down menus by 
declaring several command widgets and 
attaching them to the parent menu widget. 
We estimate that using the toolkit cut the 
code needed by more than two-thirds. 

Code reusability. Given a choice, no¬ 
body would want to write more code than 
needed to implement a certain function. 
Any reduction in code reduces the number 
of bugs to fix. Object-oriented languages 
allow the programmer to write less code 
and implement the same functionality by 
reusing code modules. This is not just a 
matter of changing parameters to a proce¬ 
dure: Vbase lets programmers paste mod¬ 
ules together as required to form larger 
modules. In addition, OODBMSs also 
support the porting of objects from one 
version to another. Types are automati¬ 
cally migrated to a new database, thereby 
eliminating the task of updating and copy¬ 
ing the object definitions. 

The simplest form of code reusability is 
to use any predefined routines that already 
exist on the system. OODBMSs typically 
provide a wide set of predefined types and 
their associated operations. For instance, 
the predefined stack object in Vbase has a 
set of routines that can be used directly, 
such as $Stack$Push, $Stack$Pop, and 
$Stack$Delete. 

Property!operation inheritance. Prop¬ 
erty/operation inheritance implies that an 
object type automatically has all the prop¬ 
erties/operations of its parent type. This is 
one of the fundamental differences be¬ 
tween OODBMSs and relational data¬ 
bases. 

From the standpoint of rapid prototyp¬ 
ing, operation inheritance is perhaps more 
valuable than property inheritance. Note 
that all the cell operations in Figure 7 are 
refinements of the operations on cell’s 
parent type. Thus, a programmer does not 
need to reimplement the behavior that a 
type shares with its supertype. More im¬ 
portantly, this allows a programmer to 
assign default behavior to objects. For 
example, we have not yet implemented 
most of the operations for register in our 
system. However, we can create or delete a 
register, or invoke several of the opera¬ 
tions defined for cell that have been inher¬ 
ited by register, since cell is the supertype 
of register. In fact, once the subtype-super¬ 
type link is established in the is-a hierar¬ 
chy, a large amount of code automatically 
becomes available to the object, even be¬ 
fore a single line of code specific to the 
new object type has been written. 



define Type Cell 

supertypes = {CktBaseType}; 
properties = { 
name: String; 

subCells: distributed Set[Cell] 

inverse $Cell$isCellOf; 
interconnect: optional SetjBus]; 

image: optional Display Image; 


}; 

end Cell; 


Figure 6. The properties clause of the 
TDL description of cell. 



define Type Cell 

supertypes = {CktBaseType}; 
operations = { 


refines Delete (c: Cell) 
raises (CannotDelete) 
triggers (CellDeleteTrigger); 

refines CreDrawEdit (c:Cell) 
method (CellCreDrawEdit); 

refines DisplayForm (c:Cell) 
method (CellDisplayForm); 


}; 

end Cell; 


Figure 7. The operations clause of the 
TDL description of cell. 


Method and trigger combination. 

Method and trigger combination involves 
writing several small modules of code and 
using them in different combinations to 
form methods for different types and situ¬ 
ations. Other disciplines such as hardware 
design have succesfully used such a build¬ 
ing-block approach. In software engineer¬ 
ing, however, the use of replaceable soft¬ 
ware modules is still not common, par¬ 
tially because of our inability to make code 
generic enough. In conventional program¬ 
ming, this would involve many checks, 
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Figure 8. Combination of methods using the automatic dispatching mechanism. 


which would make the code inefficient. 

However, with OODBMSs, the auto¬ 
matic dispatching mechanism (see the next 
section) allows programmers to combine 
modules by triggering them at the appro¬ 
priate places. Each object-specific opera¬ 
tion module is designed to handle its addi¬ 
tional set of properties and then invoke the 
corresponding module for its supertype. 
Note that all modules are invoked using the 
same generic call, irrespective of the argu¬ 
ment type. Figure 8 illustrates this for the 
operation of displaying data entry forms on 
the user interface for register, cell, and 
CktBaseType objects. 

Generic programming. In generic pro¬ 
gramming, programmers write code mod¬ 
ules as general as possible so they can be 


used by different types of objects. Two 
essential features of the object paradigm 
— polymorphism and access to metainfor¬ 
mation — help generic programming. 

Polymorphism. Polymorphism is the 
ability to automatically dispatch a call to 
an appropriate routine according to the 
type of parameters passed. This feature 
makes code upwardly compatible and re¬ 
silient to modifications. 

Consider the call back routine 
createsubO, shown in Figure 9, which is 
invoked when a user clicks on the “create” 
option in the user interface. The procedure 
GetType displays the “is-a” hierarchy and 
prompts the user to select a type. An object 
of the selected type is then created, and the 
user draws the object and fills in its nongra¬ 


phics properties using a data entry form for 
objects of this type. The CreDrawEdit 
routine does all this. Note that the 
createsubO code in Figure 9 is completely 
generic and will not change no matter how 
the Core grows. The generic call to Cre¬ 
DrawEdit is automatically dispatched to 
the appropriate method, such as CellCre- 
DrawEdit, based on the type of the object. 
The binding between the generic call and 
the object-specific routine is done in the 
TDL, as shown in Figure 7. We have found 
that the whole user interface can be devel¬ 
oped in such a generic manner. 

Polymorphism is also evident in the trig¬ 
ger and method combination example 
(Figure 8). A call to DisplayForm is auto¬ 
matically dispatched to either CBTDis- 
playForm, CellDisplayForm, or RegDis- 
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createsub() 

{ 

/* Get the type to be created by clicking in the type hierarchy tree. The function 
GetType displays the type hierarchy rooted at its argument and prompts the 
user to select a subtype. */ 

aType = $CktBaseType$GetType($CktBaseType); 

/* Call the Create, Draw and Edit routine. This call is automatically dispatched 
to the appropriate routine according to the type of “aType”. */ 

StheObject = $CktBaseType$CreDrawEdit(aType); 

) 


Figure 9. Generic subroutine for creating any circuit object. 


playForm according to the type of object 
passed. 

Accessibility of metainformation. An¬ 
other characteristic of OODBMSs that 
makes a program resilient to the addition 
of new types is the accessibility of metain¬ 
formation. The user-defined types are ac¬ 
tually objects compiled into the database. 
They are therefore available to a program 
just like any other object. 

The direct availability of metainforma¬ 
tion in the database alleviates the need to 
hard-code it in the programs. The is-a hier¬ 
archy display routine is a case in point. The 
routine reads the types from the database at 
the start of each session and creates an 
internal data structure for graphical dis¬ 
play. This ensures that the information dis¬ 
played by the program is consistent with 
the current is-a hierarchy in the database. 

Language and environment features. 

Several language features accelerate pro¬ 
gramming by catching errors early in the 
code-compile-test cycle. Both TDL and 
COP comply with some of these features. 

Although C itself is a weakly typed lan¬ 
guage, the COP compiler ensures that data¬ 
base objects can be manipulated only by 
procedures attached to them. Such strict 
type checking eliminates several hard-to- 
catch bugs early. 

The advanced exception-handling capa¬ 
bility of OODBMSs comes in handy in 
rapid prototyping. Typically, a large 
amount of code in an application’s final 
version deals with erroneous input data or 
other anomalous situations. Programmers 


would like to avoid such detailed error 
handling in early prototypes. If exceptions 
are also treated as objects, a programmer 
can initially write a simple exception han¬ 
dler for the most general type of exception. 
The programmer can then gradually refine 
this default exception handler as the proto¬ 
type grows. We did this in Cbase 1.0, 
where most exception handling was re¬ 
stricted to a print statement when an excep¬ 
tion of the type “failure” (the most general 
type of exception in Vbase) was caught. 
Several of these exceptions handlers have 
since been refined to perform context- 
sensitive error handling. 

Drawbacks and 
limitations 

While the above discussion might lead 
one to believe that the object paradigm is a 
panacea for all the woes of software engi¬ 
neering, the paradigm does have draw¬ 
backs. 

One of object technology’s disadvan¬ 
tages is the long learning curve. Most 
programmers trained in conventional pro¬ 
gramming can pick up a new language 
fairly quickly. However, object program¬ 
ming seems to require longer gestation. 
We have found that programmers normally 
need several months before they are skilled 
enough to start a project. 

Another problem that is expected in the 
initial stages of any budding technology is 
the unavailability of robust and reliable 
tools such as source-level debuggers and 
fast compilers. With packages such as X11, 


which are based on the client-server model 
and process client requests asynchro¬ 
nously, there is an associated problem in 
dealing with bugs. Error latency can 
camouflage the real bug, since the source 
line at which a program fails might not be 
the line in error. Even synchronous pack¬ 
ages such as Vbase often report errors in 
user code as some abstruse error in system 
code. 

Yet another potential problem lurks in 
the nature of abstraction. While it shields 
applications from low-level details, it also 
makes them dependent on the reliability of 
the abstraction layer. A well-hidden bug in 
this layer will show up as a rare malfunc¬ 
tion in the application layer. Since the 
application programmer does not have 
implementation-level knowledge of the 
lower layer, the bug can be almost impos¬ 
sible to isolate and eradicate, especially if 
it is disguised by asynchrony. 

Programmers must also consider per¬ 
formance carefully. The emphasis in rapid 
prototyping is typically on proof of con¬ 
cepts rather than performance. However, a 
programmer should consider performance 
as early as possible if the prototype is to 
evolve into the final system. OODBMSs 
occupy more space and are generally 
slower than the file-based systems in wide¬ 
spread use in the CAD industry. Files offer 
the rawest form of data access, while an 
OODBMS requires more storage space for 
the same data because a considerable 
amount of semantic information is also 
stored. Compile-time performance is also 
poorer in OODBMSs because of strict type 
checking (with respect to a persistent data 
structure). 

Our experience with Vbase shows that 
default object creation/manipulation op¬ 
erations provided by the environment 
might not deliver the desired level of per¬ 
formance. Fortunately, since OODBMSs 
are generally open systems, most default 
operations can be substituted by user-de¬ 
fined, object-specific operations. In addi¬ 
tion, access performance can improve via 
provisions for clustering objects on the 
disk. 

Prototyping can have an adverse impact 
on maintainability, since the finished prod¬ 
uct might consist of code that has been 
patched and modified several times. How¬ 
ever, with the object-oriented paradigm, 
the system expands primarily by the addi¬ 
tion of specialized object types. The prob¬ 
lem is automatically partitioned so that, as 
the system grows, the major changes con¬ 
sist of new code rather than modified old 
code. 
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C base 2.0 culminates about seven 
months of effort by two graduate 
students with no prior experience 
in object-oriented programming. When we 
first embarked on Cbase 1.0, we were still 
learning about Vbase and the X window 
system. Building the system as envisioned 
took approximately four months. We 
completed Cbase 2.0, which is much more 
detailed and sophisticated, in about six 
more months. We are adding more func¬ 
tionality and integrating existing programs 
in Cbase 2.0, though we have completed 
most of the structural modeling. 

By far the most important contribution 
of object-oriented technology was its 
modeling power. Complex CAD structures 
and concepts were implemented exactly as 
perceived in the real world, without the 
need to force them into predefined con¬ 
structs. In addition, the gradual refinement 
and evolutionary approach forwarded by 
OODBMSs particularly suited rapid proto¬ 
typing of an application such as Cbase due 
to the application’s ill-specified nature. 
Features such as generic programming and 
code reusability also shortened the time 



“MEMBERSHIP 

IS PART 
OF 

BEING A 
PROFESSIONAL” 

JOIN TODAY! 

For membership information, 
circle number 202 
on the reader service card. 

IEEE COMPUTER SOCIETY 

Membership Department 
10662 Los Vaqueros Circle 
Los Alamitos, CA 90720 
(714) 821-8380 


needed to complete the prototype. How¬ 
ever, the environment is not perfect; some 
special problems exist due largely to the 
newness of the technology and the lack of 
user education and experience with this 
new paradigm. 

With the increasing complexity of soft¬ 
ware systems, rapid prototyping is fast 
becoming an indispensable part of the 
software development life cycle. Our ex¬ 
perience in this project has convinced us 
that the object paradigm will be a leading 
candidate for rapid prototyping environ¬ 
ments in the coming years. □ 
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Software Storming 

Combining Rapid Prototyping and 
Knowledge Engineering 


Pamela W. Jordan, Karl S. Keller,* Richard W. Tucker, and David Vogel 
Mitre Corporation 


N o single innovation can claim to 
have made a substantial 
improvement in the effective¬ 
ness and expediency of the software devel¬ 
opment process. 1,2 Software development 
methods fall into two camps: (1) those that 
attack the development of software at the 
point of contact with the machine—that is, 
high-level software languages and soft¬ 
ware development environments 3 —and 
(2) those that attack the design and speci¬ 
fication of the software. 1,4 ' 5 Rapid pro¬ 
totyping is an amalgam of these two 
camps. It is an assessment activity that 
attempts to outline a system capable of 
solving some of the problems to be 
addressed in the target system, 5 while 
directing further study toward newly un¬ 
covered problems. 

At the Mitre-Washington Artificial 
Intelligence Center we have experimented 
with a method for rapidly producing 
highly functional prototypes. This 
method, for which we have coined the 
term software storming, involves experts 
in the initial design and implementation of 
a system during an intense development 
effort that combines knowledge engineer¬ 
ing with the latest advances in software 
development technology and workstation 
hardware. The experiment described here 
was a test of tools and techniques devel- 



Based on the 
brainstorming 
problem-solving tech¬ 
nique, this system 
development method 
produces a more 
functional prototype 
in four months than 
conventional methods 
do in two years. 


oped in the field of artificial intelligence as 
well as the first step in the development of 
software storming. Using software storm¬ 
ing, we developed a software prototype 
with significantly more functionality than 
a standard prototype in less than four 
months. 


•Keller is now with Analytic Science Corporation in 
Arlington, Virginia. 


Existing prototyping 
methods 

The primary purpose of prototyping is 
to reduce time and expense in building 
quality systems. Prototyping mandates a 
philosophy of incremental system develop¬ 
ment that includes end users in the assess¬ 
ment of emerging system capabilities. 
Increased participation of end users leads 
to faster system development and ulti¬ 
mately to more useful systems. 1 Although 
recent innovations in prototyping 1,4,6 sug¬ 
gest the importance of end-user involve¬ 
ment, they do not go far enough to bring 
the end user into software development. 

In contrast to prototyping, knowledge¬ 
engineering techniques commonly employ 
domain experts (experts in the problem 
area) as representative end users. 7 Proto¬ 
type development in knowledge¬ 
engineering sessions progresses through 
incremental refinement of a domain 
model, typically extending over two or 
more years. 

Waterman 8 identifies the following five 
stages in the evolution of an expert system: 

• Demonstration prototype: a system 
that can solve parts of a problem and 
is used to show the potential value of 
an expert system to management and 
prospective sponsors. 
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Stages of Expert-System 
Development 


Stages of 
Software Storming 


Identification 


Conceptualization 


Formalization, 

implementation, 

testing 


Revision 



WEEK 1 

Problem definition 


WEEK 2 

Action plan development 


WEEK 3 
Software storm 


WEEK 4 

Analysis and review 


FOLLOW-ON PHASE 
Revision and refinement 


STORM 

PHASE 


Figure 1. Comparison of stages of software storming with major stages of expert-system development. 4 


Research prototype: a system with 
functions for handling most areas of 
a problem, although some areas need 
further work. Some areas may 
require research in the problem 
domain. 

Field prototype: a system supporting 
all functional areas of the problem 


and being tested with end users for 
effectiveness and utility. 

Production model: a complete system 
that has been fully tested by selected 
end users but is not sold as a commer¬ 
cial product. 

Commercial system: a system ready 
for marketing. 


In our experiment we used software 
storming to develop both demonstration 
and research prototypes. Most other pro¬ 
totyping methods aim at the later stages of 
prototype system development. Those 
methods typically take a highly structured 
approach that is analogous to structured 
software design and development. Soft- 
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ware storming contrasts sharply with such 
methods in its reliance on brainstorming, 
an inherently unstructured activity, during 
knowledge engineering. 

Buchanan et al. describe five major 
stages in developing an expert system. 4 
Software storming is similar to the expert- 
system development process, employing a 
Variation of these stages in an intense, 
four-week period. Figure 1 presents a com¬ 
parison of the stages of expert-systerti 
development with the stages of software 
storming. A key difference between soft¬ 
ware storming and both expert-system 
development and conventional prototyp¬ 
ing is the time constraint placed on storm¬ 
ing. The software storm phase is a highly 
compressed step in the overall prototype 
development cycle. 

What is software 
storming? 

In addition to its time constraint, soft¬ 
ware storming differs from other pro¬ 
totyping approaches in three significant 
ways. First, in software storming, domain 
experts are intimately integrated into the 
software development process. Experts 
work cooperatively with knowledge 
engineers to incorporate knowledge into 
the system and to appraise system 
behavior. The key element Of software 
storming is bringing together experts and 
knowledge engineers for brainstorming, 
the problem-solving technique in which 
members of a group spontaneously con¬ 
tribute ideas. According io Osborn, brain¬ 
storming is “using the brain to storm a 
creative problem—and to do so in com¬ 
mando fashion, with each stormer auda¬ 
ciously attacking the same objective.” 9 
Knowledge engineering by brainstorming 
can be done rapidly with artificial intelli¬ 
gence techniques and flexible, expressive 
support tools such as AI workstations. 

The second difference between software 
storming and other approaches is that 
storm activities are videotaped to archive 
discoveries made about the problem 
domain and to provide feedback for 
improving the storming technique. Third, 
the storming process consists of two dis¬ 
tinct phases: the storm phase of intense 
development and the follow-on phase of 
extending the initial prototype to one that 
can be demonstrated. 

Effectively integrating domain experts 
into the software team requires minimiz¬ 
ing the turnaround time for software 
upgrades so as to quickly show the experts 


the implementation of their knowledge. A 
common knowledge-engineering tech¬ 
nique is to analyze experts’ performance 
as they work on familiar tasks. Software 
storming improves this technique by 
integrating the performance analysis with 
the software implementation of the 
domain expertise. In knowledge-based sys¬ 
tem development, a system generally 
represents a model of the domain as well 
as a problem-solving strategy. In software 
storming, a knowledge-based domain 
model acts as a laboratory for incremen¬ 
tally refining the problem-solving strategy. 
Problems are extracted from the emerging 
model for examination by domain experts, 
who provide immediate feedback to 
developers. 

A fundamental activity during a soft¬ 
ware storm is to capture the events of the 
storm on video, obviating the need for 
information archiving and documenting 
that are often disruptive to the software 
development process. Videotaping is a 
direct extension of audiotaping, a famil¬ 
iar procedure to knowledge engineers. 7 A 
video transcript contains a complete his¬ 
tory Of the knowledge-engineering sessions 
held during the storm. More important, 
video provides an unbiased record of staff 
interactions and progress, showing both 
failures and successes. As a result, par¬ 
ticipants can improve their software- 
storming methods. 

The two phases, storm and follow-on, 
differ in several ways. The major differ¬ 
ences are the number of people involved 
and the rate at which model construction 
progresses. Initiating software projects is 
similar to the physics of inertia: projects 
are harder to get started than to keep 
going. In light of this phenomenon, the 
storm phase requires a critical mass of 
expertise in both the problem and software 
domains. The follow-on phase continues 
at a reduced level of staffing. Follow-on 
includes cleaning up the software devel¬ 
oped during the storm phase, adding func¬ 
tions directed by the findings of the storm, 
and integrating all components. 


The stormed problem 

For our experiment we applied software 
storming to a problem in tactical commu¬ 
nications. The US Army recently began 
fielding a multibillion-dollar digital com¬ 
munications system called the Mobile Sub¬ 
scriber Equipment System, the largest such 
system ever used by the Army. 10 The MSE 
System supports the communications 



NC Node center 
LEN Large extension node 
RAU Radio access unit 
SEN Small extension node 


Figure 2. MSE connectivity. 


needs of both mobile and fixed users 
assigned to units in corps and division 
areas of operations down to the level of 
battalion headquarters and separate com¬ 
panies. 

Fixed subscribers use hardwired tele¬ 
phones at their command posts. There are 
roughly four times as many fixed sub¬ 
scribers as mobile ones. Mobile users have 
mobile subscriber radiotelephone termi¬ 
nals (MSRTs) for communicating with 
other mobile and fixed users. MSRTs 
operate in much the same way as commer¬ 
cial cellular telephones. Unlike the cellu¬ 
lar telephone industry, however, the Army 
operates in a tactical, dynamically chang¬ 
ing environment, so it does not have the 
luxury of being able to determine empiri¬ 
cally where best to place equipment. 

Figure 2 shows a generalized MSE con¬ 
figuration. Communications between any 
two users are established by a flood search 
(designed to find an optimum network 
route, among other things) through node 
center switches linked via line of sight 
(LOS) into a backbone grid network. 
Additional types of equipment connect 
localized groups of users with the node 
centers: extension nodes for fixed sub¬ 
scribers and radio access units for mobile 
subscribers. 
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Figure 3. A RAU footprint. 


Dealing with multiple constraints. The 

key problem in deploying the MSE System 
is arranging the many pieces of equipment 
on the battlefield, given army unit posture, 
equipment characteristics, and terrain 
conditions. The problem can be stated as 
follows: Given about 40 node center 
switches and 350 pieces of peripheral 
equipment, what configuration will pro¬ 
vide the best coverage to approximately 
10,000 mobile and fixed subscribers 
throughout a 35,000-square-kilometer 
corps and division area? Determining what 
“best” means is difficult because multiple, 
often conflicting, constraints must be con¬ 
sidered, including the following: 

• All fixed subscribers must be sup¬ 
ported. 

• Radio coverage should be maximized 
in areas where mobile subscribers are 
expected to be present. 

• LOS links should be maximized to 
minimize use of relay equipment. 

• Network vulnerability should be 
minimized by maximizing connec¬ 
tivity. 

Large and small extension nodes (LENs 
and SENs) service fixed subscribers and 
are allocated to military units according to 
the number of fixed subscribers they sup¬ 
port. Normally each LEN is connected to 
two node centers, whereas a SEN is con¬ 
nected to only one node center. A LEN can 


support many more fixed subscribers than 
a SEN. Extension nodes are clustered into 
groups of four to six for connection to the 
same node center, like spokes around a 
hub. Cable or LOS links are preferred for 
these connections. If necessary, additional 
LOS equipment can be used to relay 
signals. 

Radio access units service mobile sub¬ 
scribers. Normally two RAUs are con¬ 
nected to each node center, with at least 
one linked by cable. A RAU uses an 
omnidirectional signal to reach potential 
mobile subscribers. 

The crux of the problem. The area- 
radio-coverage subproblem alone is com¬ 
plex because communications signals are 
affected by the terrain over which they 
propagate. An algorithmic computation 
of signal loss relies on an involved mathe¬ 
matical model of propagation path loss. 
To understand coverage in this context 
requires a further description of the MSE 
system. 

Area radio coverage depends on the 
placement of RAUs. The area of coverage 
for a RAU is called its footprint. Figure 3 
shows a sample RAU footprint. A RAU 
footprint is the area within which an 
MSRT can communicate. Terrain features 
such as forest density, roughness, and 
urbanization strongly affect the propaga¬ 


tion losses of signals received by a RAU or 
an MSRT. No analytical methods exist to 
perform the necessary calculations. Thus, 
domain expertise in signal propagation 
must be enlisted to provide heuristic 
knowledge that enables the system to rea¬ 
son about signal loss over terrain. 

Approach to the problem. During the 
storm phase, we developed the following 
two groups of subtasks for computing an 
MSE layout: 

Data requirements: 

(1) Formulate a scenario, including 
military unit posture and terrain data. 

(2) Precompute RAU footprints for 
every possible placement of a RAU to a 
given resolution. 

(3) Precompute LOS coverage between 
locations to a specified distance at a given 
resolution. 

Functional requirements: 

(4) Place LENs and SENs to service 
fixed subscribers. 

(5) Place node centers to form a back¬ 
bone grid and to connect to LENs and 
SENs. 

(6) Place RAUs for best coverage, and 
connect them to node centers. 

This list of subtasks defined the order of 
attack for problems during the software 
week, week 3 of the storm phase. The 
order of the subtasks was determined by 
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the mutual constraints among them. 
Notice in particular that the first group 
consists of data collection or data genera¬ 
tion tasks, and the second consists of the 
primary objectives of the domain experts. 
The last three subtasks are ordered by this 
problem-solving maxim: Work on the 
most constrained part of the problem first. 
Extension nodes are constrained by the 
position of unit command posts on the 
battlefield. Node centers are constrained 
by the LOS connections to LENs and 
SENs and to other node centers, and 
RAUs are constrained by their cable or 
LOS connections to node centers. Com¬ 
puting the RAU footprints (step 2) was a 
major knowledge-engineering effort 
because, as mentioned earlier, no analyt¬ 
ical methods for solving this problem exist. 

Elements of software 
storming 

As we have said, the software-storming 
approach to rapid prototyping is two- 
phased. We recommend that the storm 
phase be short, on the order of one month, 
because fatigue and scheduling constraints 
make this phase’s level of intensity diffi¬ 
cult for people to maintain for longer 
periods. The amount of time devoted to 
the follow-on phase depends on the prob¬ 
lem being addressed, the detail desired in 
the final system’s functions, and, of 
course, how urgently the system is needed. 
In this section we describe our experi¬ 
ment’s resource and scheduling require¬ 
ments for those who may want to use 
software storming to build a prototype. 

Staffing. Five experts in developing 
knowledge-based system (KBS) software 
from the Mitre-Washington AI Technical 
Center participated in the storm phase of 
our project. One of them was also a bat¬ 
tlefield scenario expert. In addition, four 
Mitre military communications experts 
were involved. The software experts had 
no previous experience in either civilian or 
military communications planning. A 
technical manager encouraged open dis¬ 
cussion of problems and achievements 
during the storm week (described in the 
next section) and documented it all on 
videotape. 

The KBS software experts were respon¬ 
sible for knowledge engineering: inter¬ 
viewing the communications domain 
experts to learn how they would perform 
tasks and encoding this knowledge in soft¬ 
ware. The knowledge engineers were 
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selected for their wide range of experience 
in implementing knowledge-based systems 
and for their ability to work cooperatively 
without personality clashes. We consid¬ 
ered it important to choose staff who had 
been working on different projects in 
order to bring diverse viewpoints to the 
experiment. 

Two of the communications experts 
dedicated their time to the entire storm 
phase of the project. Their expertise 
encompassed two major components of 
the problem to be solved: the physical 
aspects of communications in general and 
the characteristics of the military commu¬ 
nications equipment. The two additional 
communications experts assisted during 
the storm week in the knowledge engineer¬ 
ing of key problems and in validating inter¬ 
mediate results. 

In staffing the follow-on phase, we had 
to consider who should continue the pro¬ 
totyping effort. We reasoned that it would 
be unwise to create a new team or intro¬ 
duce any new team members for the 
follow-on phase because the time to edu¬ 
cate new members would nullify the 
“jump-start” benefit of software storm¬ 
ing. The follow-on phase required fewer 
people, but for a longer period of time. 
Three members of the knowledge¬ 
engineering team were scheduled to work 
for about two months, and one domain 
expert was placed on call to support the 
follow-on effort. 

Scheduling.The storm phase consisted 
of four distinct parts: 

• Week 1—Problem definition: back¬ 
ground search, goal definition, and 
preliminary domain model construc¬ 
tion. Required two domain experts 
and two knowledge engineers. 

• Week 2—Action plan development: 


preliminary collection of software 
tools and data, construction of straw- 
man system shell, and development 
of domain problem-solving model. 
Required two knowledge engineers. 

• Week 3—Software storm: develop¬ 
ment of overall system architecture, 
implementation and knowledge 
engineering of scenario data, devel¬ 
opment of army unit layout, prelimi¬ 
nary implementation of prob¬ 
lem-solving model, construction of 
primitive user interface, and subtask 
integration. Required five knowledge 
engineers and two domain experts 
(plus two domain experts who were 
consulted on some key problems). 

• Week 4—Storm analysis: software 
cleanup and briefing with demonstra¬ 
tion to corporate management. 
Required two knowledge engineers. 

We limited the storm phase to four 
weeks to minimize its expense and its 
impact on other work under way. The 
short time also discouraged participants 
from succumbing to the tendency to let 
work expand to fill the time available. A 
five-day work week provided a con¬ 
veniently delimited duration for each of 
the four parts of the storm. Our goal was 
to accomplish each week’s activities by the 
close of business on Friday; overtime work 
should not be required for software 
storming. 

We viewed the follow-on phase as an 
extended cleanup and refinement period 
during which we would incorporate more 
detail into the initial prototype. We didn’t 
define the stages of follow-on in as much 
detail as the storm phase. And we didn’t 
commit to an estimate of the work we 
would do during the follow-on phase until 
after the storm phase. At that point we had 
a better understanding of the problem and 
were able to estimate how much additional 
functional detail the prototype needed. 

Hardware and software tools. During 
action plan development (week 2 of the 
storm phase), we decided that we needed 
four Symbolics Lisp computers. The four 
workstations would allow multiple tasks to 
be stormed simultaneously. All the soft¬ 
ware experts were very familiar with the 
Symbolics Genera software development 
environment and Common Lisp. The four 
machines were reserved in our laboratory 
for the exclusive use of the storm team dur¬ 
ing the software storm week. 

We chose ART (Automated Reasoning 
Tool), an expert-system shell from Infer- 
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ence Corporation, for knowledge repre¬ 
sentation and inferencing. Although other 
tools were available, we judged this one to 
have better tutorial documentation and to 
be faster and more sophisticated. None of 
the software stormers had used ART prior 
to the action plan development week, but 
all five had used other expert-system shells, 
both commercial and in-house. For 
backup, in case we found ART too diffi¬ 
cult to learn or use, we chose IRIS (Inte¬ 
grated Representation and Inferencing 
System), developed and used at Mitre. Its 
advantages were that two of the stormers 
were experienced in using it, and source 
code was available for modification. 

ART supports knowledge representa¬ 
tion by schemata (also called frames), in 
which objects can be related hierarchically 
and slots (attributes) of an object can be 
given values. When appropriate, values 
are inherited from higher objects in the 
hierarchy. For example, every instance of 
a LEN can support a number of fixed sub¬ 
scribers; this number is a characteristic of 
the class of all LENs, not of each instance. 
ART also provides rules in which the 
antecedents (“if” clauses) use pattern 
matching on the values in schema slots to 
select the conditions that determine what 
actions to take. These actions are encoded 
in the consequents (“then” clauses) of the 
rule. Consequents can add or remove 
knowledge from the knowledge base, pro¬ 
duce graphics, and control the application 
of additional rules. 

Along with the dynamic window soft¬ 
ware that is an integral part of the Sym¬ 
bolics Genera environment, we chose 
MMI, an in-house graphics package, for 
presentation of graphic features and 
images. To keep the number of unfamiliar 
tools to a minimum, we decided not to use 
the graphics functions of ART. 

We used the same set of software and 
hardware for both phases of our project, 
except that for follow-on we needed only 
two Symbolics Lisp machines. 

The storm phase 

The storm phase is by far the more 
interesting of the two phases of software 
storming because of its intensity and the 
amount of work accomplished in very lit¬ 
tle time. 

Background and problem definition. 

During the first week of the storm phase, 
we conducted background research to 
determine what work had been done in the 
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problem area. Most of the previously pub¬ 
lished work was restricted to network 
management 11 or backbone configura¬ 
tion, 12 but very little had been done on 
configuring mobile subscriber networks. 

We held structured interviews 7 with the 
military communications experts three or 
four times in the first week, both to learn 
more about the problem area and to decide 
how to narrow our focus to particular 
issues. The domain experts were mainly 
interested in the problem of determining 
the footprint of a radio access unit. The 
software experts believed that determining 
RAU footprints would be easy and 
decided to attempt a system that would 
configure the entire MSE System, from 
optimally placing the RAUs to laying out 
the backbone grid of node centers and 
extension nodes. They estimated that 
RAU footprint computation would be 
about one quarter of the effort. In retro¬ 
spect, this plan for the storm week was 
very ambitious. 

Action plan development. We spent the 
second week of the storm phase generat¬ 
ing the domain problem-solving model 
and selecting the hardware and software 
tools described earlier. We also developed 
the straw-man system, a software frame¬ 
work representing a first crack at the user 
interface and system functions. We now 
know that we should have devoted more 
time to fleshing out the straw-man system 
with scenario data consisting of terrain 
and military unit information. The impact 
of this lapse is described later in this article. 

At the end of the second week, we 
extracted modular subtasks of the problem 
from the domain problem-solving model. 
We assigned these subtasks to individual 
team members for implementation during 
the third week, on the basis of their previ¬ 
ous experiences and apparent interests. We 
prioritized the subtasks, selected areas for 
potential simplification, and identified 
fallbacks to pursue in case of problems. 


We considered RAU placement the most 
important task, and user interface polish¬ 
ing the least important. The fallbacks 
included switching to IRIS if ART turned 
out to be an obstacle, and making up ter¬ 
rain and unit data rather than trying to 
maintain realism if scenario construction 
became onerous. 

Software storm week. With modular 
subtasks identified and prioritized, we 
were ready to begin the implementation 
week—the software storm. Since just one 
week was allocated, we emphasized getting 
things done, not software clarity and 
documentation. Our work during the 
fourth week and the follow-on phase 
would clean up the software. 

A video camera recorded the interplay 
among the team members during the storm 
week. About 14 hours of storming were 
recorded, including hourly reports and ses¬ 
sions we deemed important, such as 
insightful interactions between team mem¬ 
bers. During the first three days, the team 
felt that videotaping was an intrusion 
because it interrupted stormers, requiring 
them to speak and demonstrate progress 
to the camera. Later, however, the 
stormers became more comfortable with 
the camera and made it an integral part of 
the storming process as they began to bet¬ 
ter understand its value. 

After the storm the videotapes provided 
an unbiased record of the group dynamics 
of the software team and of the interac¬ 
tions of the software engineers and the 
domain experts. 

Team interaction. The videotapes con¬ 
veyed the difficulties involved in com¬ 
municating ideas among members of the 
team. The same idea could be expressed 
several times over several hours or days 
before actually registering with a listener. 
Sometimes the listener didn’t know 
enough about what was being expressed to 
understand the full impact of an idea; at 
other times the listener had very different 
ideas and instantly rejected consideration 
of other ideas about a particular problem. 

The videotapes revealed some confusion 
on the first day of the software storm 
week. Even though a task allocation had 
been drawn up the previous Friday, some 
team members still had the problem of 
“Where do I start? ’ ’ For each of the sched¬ 
uled tasks, progress was slow until we iden¬ 
tified several short-term subtasks. Team 
members settled into a regular work 
rhythm by completing the short-term sub¬ 
tasks and then identifying additional ones. 
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Periodically, we integrated the software 
for several subtasks to determine what fur¬ 
ther work was necessary. 

The videotapes enabled us to observe 
the psychology of team cooperation in 
action. We saw that in some cases tasks 
had been misallocated; another person 
might be more interested in or more capa¬ 
ble of working on a problem than the per¬ 
son assigned. Also, we recognized that 
sometimes working alone is more effective 
than working with another person; 
explaining one’s approach to a task to 
another team member may simply increase 
its difficulty. It may be better to finish the 
task and then explain it to others. How¬ 
ever, when neither person knew exactly 
how to proceed in a difficult technical sit¬ 
uation and exploration was necessary, two 
team members could be more effective 
working together. 

When there seemed to be no 
documented way of implementing some¬ 
thing in ART, team members employed 
the sophisticated Symbolics software¬ 
debugging tools to find out what was 
necessary to get it done. When we found 
bugs in Mitre’s MMI package, we had no 
alternative but to fix them. When our anal¬ 
ysis seemed to show that the terrain data 
we planned to use didn’t correspond to our 
area of interest, we made up data to 
replace it. The team was well aware of the 
limited time we had for creating a proto¬ 
type, and that was a strong motivation to 
get things done. 

Knowledge engineering. The domain 
experts were essential members of the soft¬ 
ware storm team and were major contri¬ 
butors to the knowledge-engineering 
sessions. But ART, like most expert- 
system shells, requires software expertise 
for effective rule development, so it was 
not suitable for use by our domain experts 
without the aid of software experts. Thus, 
the development process was led by the 
software experts. 

With the small amount of time avail¬ 
able, it was extremely important for the 
domain experts, as well as the developers, 
to focus on storming and not be distracted. 
Our knowledge-engineering technique was 
to interview the domain experts on their 
problem-solving methods and to imple¬ 
ment these methods in the context of the 
incrementally growing model. This 
approach allowed the domain experts to 
see immediately the results of their knowl¬ 
edge operating in the system. The rapid 
feedback motivated the experts to study 
problems further. A good example of this 
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took place in the derivation of the RAU 
footprint computation model. 

The task of calculating RAU footprints 
was not as simple as we had anticipated 
and resulted in the most involved 
knowledge-engineering sessions held dur¬ 
ing the week. Other planned tasks may 
have needed complex knowledge engineer¬ 
ing, but time did not permit us to work on 
them. The sessions for calculating foot¬ 
prints started out with the following ques¬ 
tion posed to the experts: “How do you 
calculate RAU footprints?” The domain 
experts described the environmental fac¬ 
tors affecting signal attenuation and 
produced graphs and equations that rep¬ 
resented signal losses due to these factors. 
Initially the developers had some miscon¬ 
ceptions about the propagation charac¬ 
teristics of a RAU’s omnidirectional 
signals; as a result, they oversimplified the 
high-level description for calculating RAU 
footprints. After repeated explanations 
from the patient domain experts, the 
developers were able to see their error. 

At one point during testing, the 
developers found that attenuation losses 
were suspiciously high and requested that 
the domain experts return to inspect the 
results. Although the domain experts pro¬ 
nounced the attenuation losses correct, 
they were troubled by these results, and 
they conferred with an expert who had not 
been involved in the storm. The experts 
discovered that they had been counting 
some factors multiple times. They 
returned with the new expert, who 
explained the mistake, and we quickly cor¬ 
rected the problem. 

The initial knowledge-engineering ses¬ 
sion lasted three to four hours. Later ses¬ 
sions lasted about one hour each. The 
sessions followed a pattern: after discuss¬ 
ing a problem with the domain experts, the 
software engineers built software based on 
the discussions; they showed the domain 
experts the resulting software, getting 
feedback and asking additional questions. 


Eventually we reached solutions satisfac¬ 
tory to both the domain experts and the 
developers. 

Problems. During the storm week, 
problems with tools, scenario data, and 
procedures significantly slowed our prog¬ 
ress. With adequate preparation, however, 
we can avoid such problems in future 
projects. 

For two days we were very frustrated 
with the ART system, and we considered 
switching to our in-house inferencing sys¬ 
tem, IRIS. None of us had any prior expe¬ 
rience or training with ART, so it wasn’t 
surprising that we had difficulties with it. 
Although the quality of its documentation 
was high, we had to experiment to resolve 
some questions about its behavior. Thus, 
it was difficult to get work done quickly. 
Nevertheless, we decided to continue using 
ART because we had overcome many 
problems that were due to our minor mis¬ 
understandings rather than limitations of 
the software. By Thursday of the storm 
week, most of our troubles with ART had 
been resolved. It is obvious now that we all 
should have spent more time in the preced¬ 
ing weeks learning ART. 

Throughout the storm week we found 
that we were not as familiar with the data 
as we needed to be. First, we had a prob¬ 
lem with the terrain data. The terrain 
information we retrieved from our data¬ 
base did not agree with geographic maps 
of the area. We were unable to correct the 
problem during the storm week and had to 
make up data to test components that 
required terrain information. Later, in the 
follow-on phase, we discovered that when 
smaller terrain cells are grouped into larger 
cells, the larger cells are rotated with 
respect to the smaller ones, and we had not 
used the proper rotation for our terrain 
resolution. If we had examined the terrain 
data in the previous week when we were 
not so rushed, we probably would have 
discovered the problem and its cause. 

Another problem was obtaining mili¬ 
tary unit data for driving the layout of the 
extension nodes in support of the fixed 
subscribers. We spent a great deal of time 
developing the required level of detail 
from less detailed scenarios. It would have 
been better to dedicate more of the straw- 
man development in the second week to 
defining and entering unit data for the 
scenario. 

And, finally, some team members had 
concerns that quick decisions made during 
the storm phase might adversely affect 
follow-on work by locking the project into 
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a particular technique or methodology. 
For example, a knowledge representation 
expert suggested during the storm week 
that the inferencing rules be changed so 
that they would not refer to our hexagonal- 
grid form of terrain representation 
because such references might confuse our 
communications domain experts, who 
most likely were more familiar with square 
grids, and because in the follow-on effort 
we might want to abandon the hex repre¬ 
sentation in favor of another one. Due to 
the intense concentration of the software 
team during the storm week, this sugges¬ 
tion was not given much serious thought. 
The team thought such suggestions were 
distracting and would have been more use¬ 
ful in the preceding week or during 
follow-on. 

Storm phase achievements. By the end 
of the storm phase we had rules and 
methodologies for extension node layout, 
RAU footprint computation, and simple 
line-of-sight computation based on eleva¬ 
tion. Other achievements of the storm 
phase included development of the battle¬ 
field scenario, support for the hexagon ter¬ 
rain representation, and an initial user 
interface. We estimate that these were 
about 20 percent of the functions that we 
had planned to achieve. 

At the end of the storm phase we were 
far short of our goals of an initial layout 
of extension nodes and node centers and 
a method of RAU placement approximat¬ 
ing experts’ methods. However, when we 
demonstrated the functions we had 
achieved, the domain experts made two 
telling remarks: They were impressed at 
how fast we were able to understand the 
problem and provide feedback via soft¬ 
ware, and even the few functions we had 
generated were more software help than 
was currently available for this 
communications-planning problem. 

The follow-on phase 

In contrast to the storm phase, the 
follow-on phase uses a traditional 
software-prototyping approach. How¬ 
ever, its speed and its success are signifi¬ 
cantly enhanced by the jump-start effect 
of the storm phase. 

In the follow-on phase we refined and 
completed ART rules for calculating foot¬ 
prints, assigning equipment to fixed sub¬ 
scribers, and calculating LOS. We then 
tackled the problem of placing node cen¬ 
ter equipment and RAU equipment to ser- 
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vice the mobile subscribers. At this point 
we needed the results of the LOS and foot¬ 
print calculations. We had planned to 
precompute the footprint and LOS data, 
but when we attempted to do so for the full 
data set, we had problems with the amount 
of memory and runtime required. Since we 
were not able to precompute these data, we 
needed to change our approach. We 
decided to translate ART rules to Lisp 
procedures for two reasons: First, we 
decided that LOS computations did not 
require rules because they were simple cal¬ 
culations. Second, we anticipated that no 
further refinements would be needed for 
either the footprint computations or the 
equipment assignment for fixed sub¬ 
scribers. 

The ease with which we were able to 
translate rules to procedures demonstrates 
the value of an expert-system approach in 
developing prototype software. We easily 
modified and enhanced the rules until all 
the details were included and the correct 
behavior was achieved. Since all the infor¬ 
mation needed was in the rules, it was a 
simple translation process—probably sim¬ 
pler than translating from one high-level 
language to another because the control 
mechanisms did not obscure the 
knowledge. 

The value of using expert-system rules 
for prototyping was not apparent until we 
worked on placing node centers and 
RAUs. We reasoned that we would have 
time and memory problems with this task 
as we had with precomputing the footprint 
and LOS data and that therefore we 
should start out with a procedural 
approach in developing functions. But as 
development proceeded, we had to con¬ 
tinually patch the software to make any 
refinements. The Symbolics Genera soft¬ 
ware development environment, with its 
incremental development philosophy, 
made it easy to refine code, whether it was 
in rules or in procedures. However, encod¬ 
ing knowledge in rules often makes con¬ 


straints clearer and easier to maintain 
because of the declarative nature of rules. 
In retrospect, we should have used rules to 
develop new software and avoided mem¬ 
ory and time problems by using a very 
small sample of the data for testing, as we 
had with the footprint and LOS calcula¬ 
tions during the storm phase. After refine¬ 
ments were completed, we would have 
been able to translate the rules to proce¬ 
dures to handle the entire data set, as we 
had done with the footprint and LOS cal¬ 
culations. 

Knowledge engineering. In the follow- 
on phase we did not require intense inter¬ 
actions with the domain experts, as we did 
in the storm phase, because we had 
acquired much of our knowledge about 
the MSE problem during the storm phase. 
But now we believe we could have made 
some improvements in our interactions 
with the domain experts during follow-on. 
For example, we could have discussed our 
approaches for placing node centers and 
RAUs before choosing and implementing 
one approach, and we could have demon¬ 
strated our progress at more frequent 
intervals. With these steps we might have 
drawn out even more of the domain 
experts’ valuable insights. 

Problems. The only major problem we 
encountered during the follow-on phase 
was with ART. As mentioned earlier, the 
memory required to load the terrain data 
for the LOS and footprint computations 
and the time to reset the rules before the 
actual computations could begin were 
unacceptably high. Using ART rules to 
precompute LOS and footprints for the 
1,000 cells in our full terrain database 
exhausted a large amount of virtual mem¬ 
ory. By increasing virtual memory, we 
could eventually complete the application 
of rules to the data. However, resetting 
ART’s fact base for another application of 
the rules took over an hour. We described 
our problem to people at Inference Corpo¬ 
ration, who confirmed that ART could 
handle large databases, the largest to their 
knowledge containing about 10,000,000 
facts. Our database had approximately 
40,000 facts, representing terrain cells. 
Army units, and mobile subscriber equip¬ 
ment. We concluded that our relative inex¬ 
perience with ART combined with the size 
of our database might be contributing to 
the performance problems that were 
beginning to slow down our rapid¬ 
prototyping effort. 

During follow-on we performed several 


46 


COMPUTER 






experiments with ART to try to determine 
the cause of our performance problems. 
We used our full terrain data set with one 
rule that matched every item in the data¬ 
base. We found that ART was able to reset 
in about one to three minutes plus the pag¬ 
ing time, which ranged from one to four 
minutes. Given these results, we hypothe¬ 
sized that there must be some aberration 
in one or more of our rules. Our schedule, 
however, did not permit us to isolate the 
problem, and to continue the rapid prog¬ 
ress of the prototyping, we translated the 
ART rules into procedural software. 

Although our experience with ART is 
limited, we believe that such a tool is par¬ 
ticularly useful for rapid prototyping when 
it is used with a small amount of data. In 
such a case rules can be incrementally 
refined very quickly. But it is a mistake to 
use a tool if there is not at least one team 
member who is well acquainted with it. 

Follow-on phase achievements. During 
the follow-on phase full and partial solu¬ 
tions produced during the storm phase 
were collected and integrated into a 
moderately polished system that could 
configure MSE for an Army corps. The 
follow-on phase produced the remaining 
80 percent of the functions we had planned 
to achieve. 

Recommendations for 
storming 

In a remarkably short period of time, 
our software-storming experiment 
produced two significant accomplish¬ 
ments: the knowledge engineers learned a 
great deal about the problem domain, 
MSE; and an implementation of the 
experts’ problem-solving techniques was 
produced. Although we have had only one 
experience with software storming, we 
have several recommendations: 

(1) Know thy problem. Software storm¬ 
ing is not appropriate for ill-defined or 
broadly focused problems. Storming 
allows no time for research, although 
research issues may be identified during 
the course of storming. The storming 
approach requires experts who know how 
to solve problems in their domain. The 
problem to be attacked during the storm 
must be focused during the first week, the 
problem definition week. 

(2) Know thy team. The cooperation 
among members of the team during the 
storm week proved to be an important 
contribution to the success of the storm. 


Each stormer must adjust quickly to 
changing roles during the storm. We 
recommend that team members be able to 

• recognize when a task should be per¬ 
formed by a team member indepen¬ 
dently and when it requires 
teamwork, 

• relinquish a problem to another mem¬ 
ber when no progress is being made, 

• accept other members’ approaches, 
and 

• acknowledge mistakes. 

(3) Know thy tools. We would have 
made much more progress during the 
storm week if we all had had experience 
using ART. If unfamiliar tools seem 
appropriate or are required, time must be 
allotted to develop expertise in using them. 

(4) Know thy data. The data environ¬ 
ment forms the foundation of every aspect 
of software development. The quantity of 
data, the data representation, and the data 
access functions must be well understood. 
For example, a few weeks after the storm 
week we found that the terrain database 
was correct, but we were interpreting it 
incorrectly. Careful inspection of the data 
would have uncovered this misinterpreta¬ 
tion before the storm week. 

(5) Document in video. We recommend 
the use of videotape during the storm week 
for documenting the knowledge acquisi¬ 
tion process and especially for capturing 
software-storming techniques discovered 
by the team. We have used videotapes to 
review knowledge-engineering sessions, to 
study the storming experiment, and to 
educate other staff in storming techniques. 
In addition, we videotaped a demonstra¬ 
tion of the prototype at the end of the 
fourth week to complete our video 
documentation. 

S oftware storming is a useful tool 
for getting a quick grasp of a hard 
problem. It gives management a 
look into the future at how a problem 
could be solved, or if indeed it can be 
solved, before an organization commits 
itself to a major outlay of time and money. 
What distinguishes software storming 
from other methods of rapid protoyping 
is that its time frame is significantly 
shorter—three to four months instead of 
one to two years. A total of 10 staff- 
months of work was expended during the 
two phases of our experimental project. 

Whereas the typical result of rapid pro¬ 
totyping is a system shell consisting mostly 
of the user interface, storming produces a 
considerably more functional system. We 
demonstrated our prototype at an Army 


communications conference soon after the 
follow-on phase. Army MSE planners 
attending the conference judged our sys¬ 
tem to have about 75 percent of the func¬ 
tions a planner would need. 

All in all, we found software storming 
an inexpensive and highly effective tech¬ 
nique for jump-starting a prototyping 
project. □ 
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T he rise of graphical workstations 
supporting windows, icons, 
menus, and pointing devices has 
heightened interest in visual program¬ 
ming, object-oriented design, and auto¬ 
mated software design methods. 1 Graph¬ 
ics-based computing, combined with 
idealized models of the world — para¬ 
digms — has reduced learning curves, 
increased productivity, and generally 
removed the burden of program operation 
from the user. At the same time, software 
developers have come to realize that the 
user interface paradigm is itself a kind of 
programming language that expresses the 
user’s desires in pictures instead of words. 
We can characterize this evolution as a 
shift from “telling” to “showing.” 

Manuals, programming languages, and 
other written documents attempt to teach 
users and machines alike by telling them 
what to do. Showing, on the other hand, 
involves the direct manipulation of “ob¬ 
jects” without a need for manuals, pro¬ 
gramming languages, or other written 
documents and without linguistic ambigu¬ 
ity because it is direct. 

Showing a computer what to do is diffi¬ 
cult and less successful than giving it in¬ 
structions via a programming language. 
However, showing has the potential for 
major advances in programmer productiv¬ 
ity, while programming by telling has 
reached a 20-year plateau. 2 Even an imper¬ 
fect software tool for programming by 
showing can dramatically improve pro¬ 
grammer productivity. 
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By showing instead of 
telling a program 
what to do, 50-90 
percent of an application 
can be developed 
without explicit 
programming, 
increasing productivity 
two- to tenfold. 


We use the desktop metaphor of the 
Apple Macintosh as a platform or proto¬ 
typing language for expressing sequences 
of user-machine interactions. The particu¬ 
lar user interface platform is not as impor¬ 
tant as the concept of the interface as a 
language. In this article, we demonstrate 
how showing can take advantage of a stan¬ 
dard user interface and the consistency of 
a user interface paradigm. 

Showing forms the basis of the Oregon 
Speedcode Universe, a programming sys¬ 
tem for writing programs without pro¬ 
gramming languages. The heart of OSU is 

0018-9162/89/0500-0051$01.00©1989 IEEE 


its user interface prototyping tools. In 
short, OSU is a program for writing other 
programs by a combination of user inter¬ 
face design, sequencing of the user inter¬ 
face interactions, and program generation 
techniques. (For information on other tools 
that make up the complete OSU system, 
see Bose, 3 Handloser, 4 and Maithel. 5 ) 

Terminology 

A prototype Q is a collection of user 
interface objects U, a set of actions A, and 
a mapping function F: 

Q = { U,A,F) 

The user interface objects U are the 
alphabet of symbols defined by some para¬ 
digm. For example, the Macintosh desktop 
paradigm consists of user interface objects 
such as icons, pull-down menus, scrollable 
windows, and user interaction dialog 
boxes. These objects are defined using a 
resource designer, ResDez, which we will 
describe later. 

Our immediate concern is with the user 
objects in U. Each object is manipulated by 
calling its functions. A menu, for example, 
is created and manipulated by GetNew- 
Menu. In a standard user interface manage¬ 
ment system, as in the Macintosh, the 
behaviors for all user interface objects are 
defined and fixed. They constitute the 
“verbs” in the “language” of prototyping, 
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while the names of the objects constitute 
the “nouns.” 

Manipulating a member of U changes 
the internal state of the object. For ex¬ 
ample, calling the CloseWindow function 
closes an open window, and calling the 
DisableMenu function disables a menu. At 
any point, an interface is in a certain con¬ 
figuration (e.g., one window is open, an¬ 
other is closed, a menu is disabled, another 
is enabled). The sum total of the states of U 
constitutes the configuration of the user 
interface. The actions A are the behaviors 
defined on the objects of the application 
program. 

The mapping function F is a graph de¬ 
scribing state transitions from one user 
interface configuration to another. State 
transitions in F are driven by user interac¬ 
tions and the behaviors of the objects in the 
application program. 

We distinguish between a full-fledged 
application prototype incorporating appli¬ 
cation functionality and a vacuous proto¬ 
type, where the application interface is 
completely simulated but the application 
does nothing useful. 

A vacuous prototype is constructed for a 
standard user interface as follows: 

(1) Define all user interface objects in 
U\ inherit the standard user interface ob¬ 
ject’s behaviors as functions defined on 
each object. This provides a set of user 
interface objects and their functionality. 

(2) Sequence the members of U by 
connecting the functions defined for ob¬ 
jects in U to the application prototype. This 
yields a set of configurations in F. 

(3) Generate code that implements U, 
A, and F per steps 1 and 2. 

(4) Compile, link, and run the code from 
step 3. 

The central problem in our prototyping 
research is to create U, A, and F by showing 
rather than telling. In the terminology of 
object-oriented programming, the goal is 
to automatically produce objects and mes¬ 
sage-passing configurations that imple¬ 
ment a specific application. But prototyp¬ 
ing uses direct manipulation to automate 
program generation, thereby going further 
than object-oriented programming or 
programming by reusing standard compo- 

Creating vacuous prototypes is rela¬ 
tively easy. Creating full-fledged proto¬ 
types for realistic applications is possible 
if the application domain is severely re¬ 
stricted, but prototyping systems for gen¬ 
eral applications — applications that can 
be implemented by telling rather than 
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Figure 1. Software accelerators and the OSU prototyper. 
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Figure 2. Creation of a dialog box in OSU. 


showing — are beyond current technol¬ 
ogy. We claim that prototyping systems 
that can generate a wide spectrum of appli¬ 
cations will be achieved in the near term by 
combining a number of domain-specific 
tools. Our research team is investigating 
methods for doing this. 


Prototyping in OSU 

OSU is a program development system 
based on the notion of a wide-spectrum 
prototyper. OSU incorporates a number of 
domain-specific tools for automatically 
creating, manipulating, and “playing 
back” prototypes. Running applications 
are generated from OSU prototypes, cur¬ 


rently as compiled and linked Pascal pro¬ 
grams. 

First, we describe how to create a vacu¬ 
ous prototype based on the standard user 
interface and desktop paradigm of the 
Macintosh personal computer. We then 
show how to add functionality to the vacu¬ 
ous prototype using various software de¬ 
velopment accelerators. Software accel¬ 
erators are domain-dependent, accept 
direct manipulation of various objects as 
input, and produce code modules as output 
(see Figure 1). 

The heart of OSU consists of three tools 
for graphically constructing Q = { U, A, F ): 
ResDez (the resource designer), the gra¬ 
phical sequencer, and the program genera¬ 
tor. 
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Resource designer. ResDez graphi¬ 
cally creates and edits all user interface 
objects — menus, icons, dialog boxes, 
windows, alerts, error messages, prompts, 
and associated information. 3 These objects 
are “painted” on the screen exactly as they 
initially appear in the finished application. 

Figure 2 illustrates how a dialog box is 
created by direct manipulation of its size, 
shape, and items. A dialog box is 
“painted,” dragged, resized, and annotated 
with control items by direct manipulation. 
The upper portion of Figure 2 shows the 
dialog box as it will appear on the screen 
when the application runs; the lower por¬ 
tion shows a control panel for manipulat¬ 
ing the user interface object. For example, 
to place the two static texts Name: and 
Age: in the dialog box, the programmer 
uses the mouse to drag a “static text” con¬ 
trol item from the control panel onto the 
dialog box (placing the cursor on the item, 
holding the mouse button down, and mov¬ 
ing the mouse effects a “dragging” mo¬ 
tion). All items can be resized, moved, 
deleted, and renamed by direct manipula¬ 
tion. Dragging the small rectangles in the 
lower right corner of each item resizes the 

The two edit text fields are empty rec¬ 
tangles next to Name: and Age:. The rec¬ 
tangles will ultimately contain input val¬ 
ues when the dialog box is used by the 
application. Similarly, the control buttons 
Previous, Next, and Enter become active 
during program execution. 

ResDez creates each object and defines 
its initial internal state. The description of 
the object in its initial state is stored as a 
resource fork, a separate resource in the 
application’s binary file. 

The resource fork can be created sepa¬ 
rately from the actual code of the applica¬ 
tion. Indeed, a collection of menus, dialog 
boxes, and windows can be defined either 
before or after compiling the application’s 
source code. The resource fork containing 
the user interface objects is merged with 
the binary application code to form the 
application’s binary load module prior to 
“launching” it from the desktop. This sepa¬ 
ration of user interface object definitions 
from the application code that manipulates 
them is one of the Macintosh’s most pow¬ 
erful features, permitting rapid prototyp¬ 
ing and maintainable applications and 
providing a basis for constructing vacuous 
prototypes. 

Graphical sequencer. A second tool 
called a graphical sequencer partially 
creates A, the actions for transforming 



Figure 3. A sequence from the OSU graphical sequencer. 


elements of U from one state to another, 
and F, all configurations of the user inter¬ 
face. 4 Programmers use the graphical se¬ 
quencer to “play out” the application rather 
than writing instructions as a script or 
textual language. The actions of A are the 
behaviors of the desktop objects defined 
by the standard user interface (the behav¬ 
iors are provided by over 600 Macintosh 
Toolbox routines) and application objects 
defined by various software accelerators. 
The configurations of F are represented as 
a directed graph of instances of the user 
interface. 

When the programmer shows an action 
to the prototype under construction, such 
as pulling down a menu to make a menu 
selection, the graphical sequencer “calls” 


the appropriate behavior defined for the 
menu. The behavior carries out the opera¬ 
tion, thus changing the state of the object 
and the configuration of the user interface. 
Figure 3 shows a directed graph represen¬ 
tation of F for a simple sequence involving 
a menu selection and two dialog boxes. 
The dialog boxes labeled “OSU” are not 
part of the sequence; rather, they are part of 
the OSU user interface. Figure 3 is also a 
step-by-step example of how a sequence is 
built. Keep in mind that during a session 
only one dialog box or alert is on the screen 
at a time. 

The sequence starts with the program¬ 
mer selecting menu item aDialog. The 
OSU dialog box appears with a list of 
resource options for the programmer to 
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select — choosing a menu, dialog box, 
alert, etc. The order in which these objects 
are selected (by clicking the mouse on the 
corresponding items) specifies the order in 
which they are inserted into the sequence. 
In Figure 3, the programmer chooses to 
insert a dialog box first, and then specifies 
which dialog box by pointing to it (the 
display in which OSU presents all dialog 
boxes on the screen is not shown here). 

Next, the programmer must show what 
to do with this dialog box. Pushing the two 
buttons in the dialog box causes the se¬ 
quence to go in different directions, as 
shown by the branching in Figure 3. In this 
example, the left branch terminates the 
sequence and the right branch causes a 


second dialog box called a NoteAlert to 
appear on the desktop. When pushed, the 
NoteAlert’s only button also ends the se¬ 
quence. 

Figure 3 shows how easy it is to create a 
vacuous prototype consisting of a menu 
and a pair of dialog boxes. The vacuous 
prototype is nontrivial, however, because 
it contains branches and details of the 
sequence, such as what resources (menus, 
dialog boxes, windows, alerts, etc.) to 
include and what happens when each item 
of the resource is directly manipulated. 

Program generator. The third tool is a 
program generator that automatically 
writes “compilable” Pascal source code 


equivalent to the prototype defined by U 
and F in the vacuous prototype. OSU could 
have employed any of several alternative 
methods of code generation: direct compi¬ 
lation, translation into intermediate code, 
and direct interpretation. We chose source 
code generation because it takes advantage 
of compiler code optimization and gives 
the programmer access to a maintainable 
version of the program, and because the 
resulting prototypes are easily combined 
with other program components taken 
from libraries and other languages. Pascal 
source code generation is achieved by 
translation of the recorded interactions 
between user and prototype. 

A script of the recorded interactions 
between the hypothetical end user and the 
prototype is produced as an intermediate 
representation of F. The sequence script is 
written automatically in a sequence lan¬ 
guage specifically designed for OSU (this 
language is not intended for human com¬ 
prehension). Translation into Pascal is 
done automatically, and other translators 
can be used to produce C, Ada, etc. 

Figure 4 illustrates a segment of a re¬ 
corded sequence that begins with a menu 
selection — the menu is Data, and the 
selected menu item is Put. Menu selection 
leads to dialog box 204, which has three 
buttons: Previous, Next, and Enter. The 
actions defined for the first two buttons are 
specified by active objects with behaviors 
GetPrevious and GetNext. The third but¬ 
ton, Enter, is defined by a two-object se¬ 
quence: display of Alert 302 followed by 
active object CloseDialog. 

Figure 5 contains the script generated by 
translating F from Figure 4. The keyword 
ItemHit designates events; indentation 
designates nested actions; and verbs such 
as Open, InsertStr, Close, and Do have 
obvious meanings. In this example, 
ItemHit=Data [4=0] specifies the event 
corresponding to the user selecting menu 
number 4 (Data), and ItemHit=Put [4=2] 
specifies selection of Put, which is item 
number 2 in the Data menu (number 4). 
Open Dialog [204] specifies dialog box 
number 204 from the resource fork as the 
user interface object to display following 
the menu selection. 

Three events can occur at this point. 
ItemHit=DitlItem [1=D204=B] corre¬ 
sponds to the user selecting the Enter but¬ 
ton (item number 1 ir. dialog box 204). 
When this happens, Open Alert [302=A3] 
displays alert number 302; InsertStr 1 
[104] shows the string “Don’t forget to 
save your changes” in the alert; 
ItemHit=DitlItem [1=A302=B] waits until 
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ItemHit=Data [4=0]; 

ItemHit=Put [4=2]; 

Open Dialog [204]; 

ItemHit=DitlItem [1=D204=B]; 
Open Alert [302=A3]; 

InsertStr 1 [104]; 
ItemHit=DitlItem [1=A302=B]; 

Close Dialog [204]; 

ItemHit=DitlItem [3=D204=B]; 

Do [GetPrevious]; 

ItemHit=DitlItem [2=D204=B]; 

Do [GetNext]; 


unit Groupl_my App; 
interface 

Declarations_my App, Globals_myApp, SystemCalls_myApp, 

UserProcedures_myApp, SimpleAlert_myApp, SimpleDialog_myApp; 
procedure Dialog204 (Dlogld204 integer; 

screenport :Grafptr); 

implementation 

[User Dialog Procedures/Functions} 
procedure Dialog204 [Dlogld204 integer; screenport :Grafptr] 

itemHit integer; 
theDialog :dialogptr; 

Done :boolean; 
currentport :Grafptr; 


.; begin 

getport(currentport) 

theDialog := GetNewDialog(Dlogid204, nil, Pointer(-l)); 

- Show Window(theDialog); 

Figure 5. Sequence script correspond- Setport(theDialog); 

ing to Figure 4. Done ;= false; 

repeat 

ModalDialog(nil, itemHit); 
case itemHit of 


the OK button in alert 302 is pressed; and 
finally. Close Dialog [204] removes the 
dialog box from the screen. 

The other two possible events in Figure 
4 are represented in Figure 5 by the scripts 
ItemHit=DitlItem [3=D204=B] and 
ItemHit=DitlItem [2=D204=B]. The user 
procedures GetPrevious and GetNext are 
called, respectively, when these two events 
occur. Thus, the Do command provides an 
open-ended method for connecting vacu¬ 
ous sequences to application functions. 
These functions are generated automati¬ 
cally by various software accelerators or, 
alternately, by hand. 

Figure 6 is a sample of the code gener¬ 
ated. It corresponds to the lines of script in 
Figure 5 starting at Open Dialog [204], 

Software accelerators. As mentioned 
earlier, software accelerators accept direct 
manipulation of various objects as input 
and produce code modules as output. By 
convention, data and the operations that 
can be performed on the data are encapsu¬ 
lated in the form of a module. This pro¬ 
vides a homogeneous code interface to 
OSU and the standard user interface ob¬ 
jects. The uniformity of code interfaces 
across all objects in the system enables 
OSU to import application functionality 
from domain-specific tools. We briefly 
describe some tools under development 


begin 

Alert302(302, screenport); 

done := true; 
end: [case of 1) 

2 : 

begin 

GETNEXT; 
end; [case of 2} 

3 : 

GETPREVIOUS; 
end: (case of 3} 
otherwise 
begin 
end; 

end; [case] 

until (done); 

DisposDialog(theDialog); 

Setport(currentport); 

if (itemHit =1) then 
begin 
end; 

if (itemHit = 2) then 
begin 
end; 

if (itemHit = 3) then 
begin 
end; 

end; [procedure Dialog204] 


Figure 6. A sample Pascal code corresponding to Figure 5. 
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in the sidebar below. 

Meta-ECR is a software accelerator for 
designing and creating databases accord¬ 
ing to the entity-category-relation model. 5 
A diagram like the one in Figure 7 is drawn 
on the Screen to create entities, relations, 
and categories. These database objects 
have defined attributes that are manipu¬ 
lated by various database routines such as 
Insert, Delete, Sort, and Lookup. 

Rectangles such as Person and Classes 
represent entities — files that contain in¬ 
formation such as Names and Ages of 
people (Person). A diamond (Takes) repre¬ 
sents relationships between two entities. 


For example, a student from the Person file 
Takes a class listed in the Classes file. 
Entities can be subdivided into categories 
as shown by the two octagons (Graduate 
and Undergrad) — students take under¬ 
graduate and graduate classes. The struc¬ 
ture of a Meta-ECR file is defined by its 
attributes, such as Name and Age. The 
structure information is used to convert 
each Meta-ECR file into a relational file in 
dBase III format. 

Because OSU treats relational file op¬ 
erators as behaviors, an application de¬ 
scribed in OSU can use a Person file de¬ 
fined and created by Meta-ECR as shown 


in Figure 7. Suppose a dialog box for cap¬ 
turing Name and Age is specified as part of 
a sequence by OSU’s graphical sequencer, 
as shown in Figure 4. The values entered in 
the dialog box are inserted in Person by 
connecting the Insert file operator with the 
Name and Age fields of the dialog box. To 
do this, the prototype is linked with the 
Insert routine as if Insert is an active object 
in the sequence. (An active object defines 
functionality, versus a user interface ob¬ 
ject that appears on the screen.) The result¬ 
ing script would contain ItemHit clauses 
with Do [Insert] commands corresponding 
to each of the two fields, Name and Age. 


Comparision of direct graphical specification systems 


A variety of rapid prototyping systems have been con¬ 
structed. For example, the SmethersBarnes Prototyper is a 
commercial system similar to Oregon Speedcode Universe. 
Prototyper combines the design of user interface objects with 
sequencing in a more elegant and seamless interface than 
OSU, but Prototyper is not as extensible as OSU. 

Next Computer's Interface Builder is a tool very similar to 
OSU, except the runtime binding capability of Objective-C 
permits even closer integration of functionality with the user 
interface prototype. Interface Builder allows a source and 
destination object to be connected by a message. Once a 
connecting message is specified, the object is incorporated 
into the application without intermediate steps. The ability to 
connect objects in this fashion is extremely powerful and 
goes beyond OSU's current capabilities. Interface Builder and 
OSU both depend on domain-dependent code generators to 
extend their capability beyond mere interface prototyping. 

In addition, a variety of experimental systems have been 
constructed. These range from user interface design tools to 
application generators. We list the most prominent ones be¬ 
low: 

• Menulay' allows a programmer to directly manipulate 
user interface objects in much the same way as the RezDez 
portion of OSU. Each control is associated with a semantic 
routine that is also reminiscent of OSU’s object-oriented ap¬ 
proach, but Menulay’s rigid, table-driven structure limits inter¬ 
action between the semantic level and the user interface, pre¬ 
venting semantic feedback . 2 

• Trillium 3 is similar to Menulay, with the added capability of 
immediate interpretation of the user interface prototype. Like 
OSU, Trillium interfaces can be “played back” on demand. 
Unlike OSU, Trillium cannot link user interface configurations 
to form a sequence that mimics the actual application. 

• Rapid 4 (Rapid Prototyper for Interface Design) resembles 
Trillium. If is designed to allow nonprogrammer design engi¬ 
neers to prototype control panels for residential and office 
products at Honeywell, such as security systems and thermo¬ 
stats. 

• Rapid/Use 5 is a set of techniques supported by tools to 
specify and implement interactive information systems. Use 
supports the construction of prototypes and partial systems 
from two automated tools: the Transition Diagram Interpreter 
and a relational database management system. Functions are 
added to the partial application by writing code in the tradi¬ 
tional manner. 

• Grins 6 (Graphical Interaction System) UIMS combines a 


grammar processor (an “interactive push-down automa¬ 
ton”) with a constraint-based “input-output linkage" system 
to handle semantic feedback. It incorporates a graphical 
editor that allows the interaction techniques (menus, 
icons, and text areas) to be placed on the user's screen 
using a mouse. 

• Peridot 7 (Programming by Example for Real-time Inter¬ 
face Design, Obviating Typing) allows a programmer to 
design new interfaces by direct manipulation of rec¬ 
tangles, circles, text, and lines. Peridot can produce ex¬ 
ecutable code from showing sequences much like OSU. A 
programmer can create standard user interface objects in 
Peridot, but standard objects such as menus and windows 
are not assumed. Thus, a programmer must construct 
these from low-level graphical structures such as rec¬ 
tangles and lines. OSU, on the other hand, assumes the 
higher-level user interface objects of the Macintosh. A pro¬ 
grammer need not reinvent these objects. However, non¬ 
standard user interface objects cannot be created in OSU, 
whereas they can in Peridot. 
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Implementation 
strategy of OSU 

We faced three design questions in 
implementing OSU: 

(1) How do we create and edit user in¬ 
terface objects? 

(2) How do we capture and represent 
showing by direct manipulation? 

(3) How do we generate a running pro¬ 
gram from the prototype? 

The Macintosh’s software architecture and 
standard user interface heavily influenced 
our decisions, A short introduction to the 
Macintosh architecture will explain how 
we arrived at the answers to these ques¬ 
tions. 

Macintosh software design. All 

Macintosh software depends on the ROM- 
based Toolkit, which contains hundreds of 
operations for supporting the standard user 
interface. It also contains most operating 
system “calls” needed to manipulate user 
interface objects such as menus, dialog 
boxes, and windows. Interestingly, the 
definitions of on-screen objects can be 
separated from the ROM-based access 
procedures that manipulate them. Instead 
of “hardwiring” the user interface objects 
into the application program’s logic, 
menus, dialog boxes, and windows can be 
separately defined by a set of parameters 
stored in the application’s resource fork. 

Figure 8 shows a menu and a window 
definition. The visual display of a user 
interface object is dictated by its resource 
fork parameters. Given a parameterized 
specification, the object can be “compiled” 
into a binary resource and linked with the 
application’s program code to form an 
executable application. Conversely, given 
the graphical display as shown on the 
screen, a parameterized specification can 
be computed and stored as a resource. 

This i$ the basis of ResDez, OSU’s re¬ 
source designer. ResDez accepts graphical 
objects as input and produces a parameter¬ 
ized resource fork. This fork is linked with 
the code generated by the program genera¬ 
tor and compiled by the Macintosh Pascal 
compiler. 

To create and edit user interface objects 
(our first design question), ResDez “de¬ 
compiles” graphical user objects into re¬ 
source fork parameters and stores them in 
the resource fork of the target application’s 
binary file. In addition, ResDez can extract 
resource fork parameters from other appli¬ 
cations and add them to the target applica¬ 
tion’s resources. Thus, user interface ob- 



Figure 7. An entity-category-relationship diagram is a model of a database. 
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Figure 8. Specification of user interface objects as resources: (a) a menu as it is 
displayed and as it is defined in a resource fork; (b) a window as it is displayed 
and as it is defined in a resource fork. 


jects can be reused from application to 
application. 

The sequencer language. The second 
design question is more difficult. Showing 
by direct manipulation does not give 
enough information to fully specify the 
sequence of operations to be carried put by 


a rich user interface, because some ma¬ 
nipulations trigger more than one opera¬ 
tion, and others cause side-effects. Fqr 
example, a menu selection might trigger an 
open dialog box, placement of a check 
mark next to the menu item, and initializ¬ 
ing values in the application. 

Multiple operations are triggered in a 
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vacuous prototype by specifying miniature 
subsequences through intermediate OSU 
dialog boxes that accompany direct ma¬ 
nipulation of the user interface object. 
These subsequences consist of housekeep¬ 
ing chores such as placing check marks 
next to menu items and placing more than 
one event in each ItemHit clause corre¬ 
sponding to a major event. 

We can solve the side-effects problem 
by permitting user-defined procedures to 
be inserted in the sequence as if they were 
user interface objects. These active objects 
are produced by hand or by software accel¬ 
erators. If produced by hand, OSU pro¬ 
vides CASE-like tools for structured de¬ 
sign. If produced by a software accelerator 
such as the database designer tool, the 
behaviors of the object are integrated into 
an OSU sequence as an active object. OSU 
presents the user with a series of lists from 
which to select the appropriate collection 
of objects and assists the user in such de¬ 
tails as matching actual parameters to for¬ 
mal parameters. The lists depend on the 
source and type of active object being 
managed. 

This approach is admittedly akin to tell¬ 
ing rather than showing. Although this 
means OSU must be operated by knowl¬ 
edgeable programmers, we have designed 
OSU to increase the productivity of expe¬ 
rienced programmers, not end users and 
novices. 

Program generation. OSU produces a 
shell program to take events from an event 
queue, process them according to the 
sequences provided by the graphical se¬ 
quencer, and repeat this cycle until it en¬ 
counters a “quit” event. The shell program, 
called the main event loop , is the same for 
all applications produced by OSU. 

Source code is generated by parsing and 
analyzing the script produced by the gra¬ 
phical sequencer. Why generate execut¬ 
able code indirectly through a high-level 
language rather than directly produce a 
machine language version of the proto¬ 
type? 

(1) It is simple. Since this is an experi¬ 
mental system, we are more interested in 
studying what can be done without pro¬ 
gramming languages than we are con¬ 
cerned about which language to use as a 
target. 

(2) It is flexible. A high-level language 
such as Pascal can be read and understood 
in its source code form, changed or en¬ 
hanced so that weaknesses in the program 
generator can be overcome by patches to 
the emitted code, and linked with routines 



We have designed OSU to 
increase the productivity 
of experienced 
programmers, not end 
users and novices. 


written in another language or with librar¬ 
ies of routines produced by other pro¬ 
grams, such as the software accelerators 
described above. 

(3) It is convenient. Sophisticated pro¬ 
gramming environments for high-level 
languages permit symbolic debugging, 
incremental compilation, and performance 
analysis. Project control and management 
of large software projects such as OSU are 
nearly impossible without such program¬ 
ming environments. 

To generate a running program from the 
prototype (our third design question), OSU 
performs source code generation in two 
parts: 

(1) A parameterized “macro” main 
event shell program containing metavari¬ 
ables is copied and modified to produce a 
main event loop program. Modification 
consists of replacing all metavariables 
with actual values. For example, the 
metavariable defining the number of appli¬ 
cation menus is replaced by a constant 
value, and the application’s desktop icon is 
supplied from the resource fork. 

(2) Modules containing encapsulated 
objects are either generated from the se¬ 
quence language or imported from librar¬ 
ies containing them. These modules are 
“used” by the main event loop program and 
linked to the running application by the 
compile/link process required of all Pascal 
programs. 

The parameterized macro used to pro¬ 
duce the main event program contains 
many standard features of applications that 
use the standard Macintosh user interface. 
For example, coresident programs called 
DAs (Desk Accessories) are allowed to 
activate from within any Macintosh appli¬ 
cation. But DAs must be specifically 
managed by the application, so the shell 
program must include this code. 

The shell macro can be replaced by other 
shell macros incorporating an array of 
features considered standard within cer¬ 
tain application domains, such as telecom¬ 
munications, networking, and laser print¬ 
ing. 


External modules connect to the shell 
program by inserting a “uses” clause in the 
shell. The uses clause is a mechanism for 
importing and exporting constants, types, 
variables, procedures, and functions that 
are visible from outside a unit. Thus, 
modules are coupled via their interface 
parts and access procedure invocations. 
The program generator must know the unit 
name and procedure/function name of 
every operation used by the application. 
The graphical sequencer includes this in¬ 
formation in the sequence of events passed 
to the program generator. 

A major obstacle to this simplistic ap¬ 
proach to program generation is the nonhi- 
erarchical nature of events and the opera¬ 
tions on these events. We can demonstrate 
this by a simple example. Suppose two 
distinct portions of the prototype contain 
the following two sequences of events: 

A: 

ItemHit=Menu 

ItemHit=Dialog 

ItemHit=Alert 


B: 

ItemHit=Menu 

ItemHit=Alert 

ItemHit=Dialog 


Sequence A contains a call to the mod¬ 
ule Alert from the module Dialog (Alert 
uses Dialog). Sequence B contains a call to 
the module Dialog from the module Alert 
(Dialog uses Alert). If the program genera¬ 
tor blindly uses the modules in the order 
specified by sequence A, then the hierar¬ 
chy built will be A: Menu—^Dialog—»A1- 
ert. When the program generator encoun¬ 
ters sequence B, the hierarchy built will be 
B: Menu->Alert->Dialog, which does not 
match the hierarchy of sequence A. This 
“deadlock” between the two sequences 
shows up as a compiler error if not re¬ 
moved. 

OSU cannot automatically produce a 
purely object-oriented hierarchy among 
objects because Alert uses Dialog and 
Dialog uses Alert. It is tempting to move 
Alert and Dialog to the same level and add 
a supervisory module, but this fails be¬ 
cause of attempted forward referencing 
that occurs when compiling the supervi¬ 
sory module. Instead, OSU splits nodes by 
code duplication, resulting in inefficiency. 
This general problem for all rapid proto¬ 
typing systems is a matter of current re¬ 
search interest. 6 
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M yers’ 6 survey of prototyping 
technology using various user 
interface tools lists several 
problems with current systems: 

(1) Too difficult to use. Most systems 
require the programmer to learn a new 
prototyping language. Direct manipula¬ 
tion systems such as OSU largely over¬ 
come this problem, but even OSU requires 
knowledge of the Macintosh software 
architecture. OSU is for programmers, not 
end users. 

(2) Too little functionality. Most sys¬ 
tems are limited to menus and simple dia¬ 
log boxes, resulting in a vacuous proto¬ 
type. OSU is aimed at wide-spectrum 
prototyping, but its functionality also is 
limited in its current state. Many software 
accelerators must be designed and imple¬ 
mented, and work is under way to imple¬ 
ment several domain-specific software 
accelerators for OSU. OSU cannot, for 
example, generate itself. 

(3) Not available/not portable. Exist¬ 
ing systems depend on the host system. 
OSU is intimately connected to the Macin¬ 
tosh and would require extensive rewriting 


to be ported to another system, such as X 
Windows. We doubt that portability is 
desirable for such systems, but availability 
should be a high priority. OSU is available 
to a limited number of researchers. 

Myers reports a number of other prob¬ 
lems including a lack of evidence of the 
worth of user interface prototyping sys¬ 
tems; the difficulty of understanding and 
editing specifications; a belief by program¬ 
mers that user interfaces developed by pro¬ 
typing will suffer in quality; programmer 
unwillingness to give up control; the diffi¬ 
culty of building good tools; an absence of 
support for evaluation of the resulting 
prototypes; and the difficulty of separating 
the user interface from the rest of the appli¬ 
cation. OSU overcomes many, but not all, 
of these problems. 

Our original goal for OSU was a two- to 
tenfold increase in programmer productiv¬ 
ity. Several experiments have suggested 
that this is possible. In an experiment con¬ 
ducted on a software project at Oregon 
State University, the original source code 
was 6,000 lines long and was worked on by 
a team of six expert programmers over a 


period of six months. Using OSU, one 
programmer reproduced 73 percent (4,383 
lines) of the code in less than 3 hours. This 
was possible because the original project 
consisted of over 70 percent user-interface 
code. This represents a 3.3-fold increase in 
productivity. In general, we can speed up 
programming by S = 100/(100 - s), where 
s is the percentage of code produced by 
showing rather than telling. 

OSU demonstrates the power of stan¬ 
dard user interfaces in prototyping. When 
a standard interface is assumed, the stan¬ 
dard user interface objects become a kind 
of very high level language for showing 
rather than telling. It is this power we 
explored by designing and implementing 
OSU. Work remains to refine and extend 
these ideas to encompass a greater diver¬ 
sity of applications. 

We should mention that OSU departs 
from the more traditional approach of very 
high level languages, executable specifi¬ 
cations, and expert systems prototyping. 
These are predominately textual ap¬ 
proaches based on telling rather than show¬ 
ing. In addition, most textual systems de- 
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methodology, bit-mapped graphics and window en * 
vironment, image processing, and multi-media data¬ 
base management. Occasional participation in 
at-sea operations may be required. Apply to: 
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pend on abstraction, while OSU is based on 
concreteness of the objects being manipu¬ 
lated. We purposely avoided textual ap¬ 
proaches so we could learn to use direct 
manipulation (showing) and concreteness 
in automatic programming. Early indica¬ 
tions are encouraging and suggest that we 
can gain much by adopting nontextual 
methods and using concreteness instead of 
abstraction. □ 
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A Rapid Prototyping Facility 
for Flight Research in 
Advanced Systems Concepts 

Eugene L. Duke, NASA Ames Research Center, Dryden Flight Research Facility 
Randal W. Brumbaugh and James D. Disbrow, PRC Systems Services 


N ASA has long recognized 
America’s need for a rapid pro¬ 
totyping facility (RPF) for flight 
research. At the Dryden Flight Research 
Facility of the NASA Ames Research Cen¬ 
ter (Ames-Dryden), the concept of an RPF 
evolved from experience with remotely 
piloted research vehicles and from experi¬ 
ence with digital flight-control systems on 
vehicles such as the three-eighths scale F-15 
remotely piloted research vehicle and the 
F-8 digital fly-by-wire (DFBW) aircraft. 

The rapid prototyping flight-research 
facility, also known as the remotely aug¬ 
mented vehicle (RAV) facility, has been 
used to test control-law concepts on the 
F-8 DFBW aircraft. 1 The RAV concept 
was developed to aid in testing advanced 
or multiple alternate vehicle control 
algorithms without the expensive and 
time-consuming process of repeated air¬ 
craft systems modifications. Other uses 
include implementing the primary control 
laws for remotely piloted research vehicles, 
such as the three-eighths scale F-15 aircraft 
and the highly maneuverable aircraft tech¬ 
nology (Himat) 2 vehicle, and providing a 
remote computation facility for cockpit 
displays. 



NASA recognizes that 
the United States 
needs a flight-research 
facility dedicated to 
rapid avionics 
prototyping. The 
agency is now 
developing the Ames- 
Dryden facility to 
meet that need. 


The facility described in this article is 
intended as an adjunct to the usual 
avionics development process. This pro¬ 
cess generally includes using research and 
development laboratories, increasingly 
complex simulators, and, occasionally, an 
expensive and often one-of-a-kind, single¬ 


purpose, flight demonstrator vehicle. 

In a sense, the RPF for advanced sys¬ 
tems concepts described here simply 
extends the more elaborate high-fidelity 
simulators. However, this facility is more 
realistically viewed as a bridge between 
simulation and demonstration devel¬ 
opment. 

The RPF for flight research in advanced 
systems concepts provides a reusable and 
flexible general-purpose capability for 
early solution of problems certain to arise 
in future development programs. Addi¬ 
tionally, using this facility will provide the 
benefits of flight research that Szalai 
described 3 : 

(1) Separating real from imagined 
problems. 

(2) Uncovering the unexpected and the 
overlooked. 

(3) Forcing realistic pilot integration. 

(4) Stimulating development of credi¬ 
ble prediction, test, and qualifica¬ 
tion processes. 

(5) Requiring every anomaly to be 
addressed. 

(6) Spurring timely technology transfer 
and the building of a core technical 
team. 


May 1989 


0018-9162/89/0500-0061$01.00©1989 IEEE 






These issues are not insubstantial. Flight 
research forces one to focus on real prob¬ 
lems often inconceivable in a simulation 
environment. This is particularly true with 
new concepts such as knowledge-based 
flight systems, for which we have little 
application experience. Without flight 
research in knowledge-based flight sys¬ 
tems, many of the wrong issues will be 
addressed, and many of the right problems 
will be overlooked. 

For flight research to occur, two serious 
issues—pilot-vehicle integration and sys¬ 
tem qualification—must be addressed 
related to incorporating knowledge-based 
systems (KBSs) technology in aircraft. 
Experience has shown that, for a new class 
of applications, these issues are unlikely to 
be viewed in the proper perspective with¬ 
out the focus of a flight program. Flight 
research will allow real problems to be 
solved and real solutions to be found and 
disseminated. Within this perspective, 
NASA has undertaken a project that 
extends an already existing capability into 
a facility that can support research in 
knowledge-based flight systems concepts. 

The RAV facility has been extended to 
an RPF for flight research in advanced sys¬ 
tems concepts based on conventional tech¬ 
niques, artificial intelligence, or a 
combination of the two technologies. The 
RPF includes real-time, high-fidelity air¬ 
craft simulators, conventional and sym¬ 
bolic processors, and high-performance 
research aircraft specially modified to 
accept commands from on-board and 
ground-based research computers. 


The need for an RPF 
for KBS 

An early step in developing a KBS 
generally includes implementing a proto¬ 
type system. 4 Such a prototype KBS pro¬ 
vides a means of assessing concept 
feasibility and preliminary knowledge¬ 
base implementation, knowledge repre¬ 
sentation, inference strategy, heuristics, 
and other design and implementation 
issues. Additionally, a prototype system 
serves to gain or maintain user and 
management support and provides a 
mechanism for promoting a larger, more 
comprehensive program. 

A KBS is often implemented using 
general-purpose expert system building 
tools that allow rapid prototype-system 
deployment. Although much of the envi¬ 
sioned final system is simulated, the pro¬ 


totype system is sufficiently realistic 
(usually in the form of a rudimentary 
knowledge base) to enable both overall 
concept assessment and initial knowledge 
base validation. 

Implementing a prototype system early 
in KBS development can lead to problem 
identification and solution before initia¬ 
tion of the first actual design iteration. 
Schutzer made this point in describing 
how, using rapid prototyping, a system 
“design is verified through actual trial and 
use rather than through review and sign- 
off of paper documents.” 5 Simply by 
addressing problems (or potential prob¬ 
lems) early in the development cycle, 
researchers can often avoid many costly 
and time-consuming exercises associated 
with the late introduction of design 
changes and software modifications. 

Duda and Gaschnig described the issues 
of support software for applied AI 
research, knowledge acquisition, and 
knowledge representation as major prob¬ 
lems that occur because “we are now wit¬ 
nessing the first transition of expert 
programs from the comfortable surround¬ 
ings of research laboratories to the more 
demanding outside world. ” 6 Many prob¬ 
lems surface in the world outside the 
research laboratory. Using flight research 
and simulators early minimizes the effects 
real-world problems can have on the 
schedule, operation, and deployment of 
KBSs embedded in avionics systems. 

Applying KBSs to aircraft problems 
requires both human-machine and 
machine-machine interfaces. The avionics 
environment is noisy and complex. Incor¬ 
porating KBSs inside an aircraft requires 
interaction with complex systems that are 
difficult to model and simulate accurately. 
This is a severe problem for applications 
involving control functions. All these 
issues carry the potential for greatly 
increasing the problems of implementing 
KBS-based avionics. 

Even though the major well-known sys¬ 
tems were applied in relatively benign and 
forgiving environments, the need for rapid 
prototyping has been recognized in applied 
AI. Research chemists use Dendral 7 ; geol¬ 
ogists and mining engineers use 
Prospector 8 ; and, primarily, artificial 
intelligence research laboratory personnel 
use Mycin. 9 Although the designers 
encountered problems in developing the 
human-machine interface for these sys¬ 
tems, they did not address many of the 
problems knowledge-based avionics sys¬ 
tems designers faced. Sophisticated users 
meant that many limitations of the listed 


systems were minimized or went 
unnoticed. 

Typically, the laboratory environment 
is clean and uncontaminated. Requiring a 
knowledgeable human to act as an agent 
of the system protects these KBSs, to a cer¬ 
tain extent, from obviously erroneous 
inputs or conclusions. In addition, while 
a human-machine interface might be dif¬ 
ficult for avionics applications, a machine- 
machine interface can prove much more 
difficult and certainly less forgiving. 

The premise behind extending the RAV 
facility into a more capable facility accom¬ 
modating knowledge-based flight systems 
research is that we need such a facility 
because of the problems associated with 
KBSs embedded within aircraft avionics 
systems. These systems certainly will meet 
the criteria Schutzer set down 5 when he 
said, “This [rapid prototyping] is clearly 
a preferred design mode for highly inter¬ 
active man-machine systems and for new 
systems that have little historical 
precedence.” 

Using the RAV concept 
for rapid advanced- 
systems prototyping 

Understanding the RAV concept is 
essential for understanding the RPF. The 
RAV facility has provided a unique means 
of conducting flight research in conven¬ 
tional flight controls and guidance on a 
variety of aircraft. Both cost and imple¬ 
mentation complexity compare favorably 
to using highly sophisticated, full-mission 
simulators. We provide a RAV concept 
example applied to the F-8 DFBW aircraft 
to illustrate applications in conventional 
systems. 

Key RAV concept elements. As shown 
in Figure 1, the key elements of the RAV 
concept include a ground-based auxiliary 
computational facility, a specially modi¬ 
fied aircraft, and a simulator. Each ele¬ 
ment performs a unique function that 
facilitates rapid transition from simulation 
to flight. This rapid transition capability 
is the most powerful argument for the 
RAV concept. It enables a concept to be 
flight-tested using a RAV facility nearly as 
soon as a flight system concept can be 
demonstrated on a simulator. 

The auxiliary computational facility. 
The current ground-based auxiliary com¬ 
putational facility for rapid prototyping 
conventional systems contains a downlink 
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receiver; a suite of conventional, numeric 
computers; and an uplink transmitter (see 
Figure 2). Downlink telemetry is received 
and relayed to the ground-based com¬ 
puters that execute the necessary calcula¬ 
tions and then uplink commands to the 
aircraft. Because the computers used in the 
simulator and the flight systems are iden¬ 
tical, software developed in the simulator 
can be easily shifted into the flight systems 
without modification. 

The main advantage of equipping a 
ground-based computational facility as 
described is that it makes equipping the 
facility with flight qualified, military spec¬ 
ification computers unnecessary. Thus, 
laboratory quality computers can be used 
in the ground facility. The differences in 
these requirements allow state-of-the-art 
computers to be used in the ground-based 
flight systems. In fact, even breadboard 
computers could conceivably be used in 
the ground-based systems. 

Another advantage of the ground-based 
auxiliary computation facility is that soft¬ 
ware changes do not require aircraft 
modifications. This pays dividends in cost, 
schedule, and flight safety. 



Figure 1. Remotely augmented vehicle concept. 



The research aircraft. Aircraft used in 
a RAV flight-research facility require two 
main modifications. In the first modifica¬ 
tion, sensors and a high-quality data 
instrumentation subsystem are added. The 
data this subsystem collects is transmitted 
to the auxiliary computation facility using 
a telemetry downlink. The other necessary 
modification involves installing and 
integrating an uplink receiver in the air¬ 
craft. If closed-loop control is desired, the 
uplink is interfaced to the flight-control 
subsystem. If the uplink is used for display 
purposes, the interface is tied to the on¬ 
board display subsystem. Both uplink 
functions can be incorporated simultane¬ 
ously. The aircraft requires no further 
modification after the test aircraft has 
been configured with the instrumentation 
subsystem, the downlink transmitter, and 
the uplink receiver incorporated into the 
overall avionics system. 



3 


Figure 2. Configuration of a ground facility for rapid prototyping of conventional 
systems in a RAV system. 


The simulation facility. The simulator 
is used for flight systems development, 
verification, and validation. These simu¬ 
lators vary from simple software models 
of the vehicle aerodynamics and equations 
of motion to complex flight-hardware-in- 
the-loop implementations. However, these 
simulators must include sufficient realism 
and flight hardware to permit developing 
flight systems concepts. By including flight 


hardware in it, the simulator is trans¬ 
formed into an integration and software 
validation facility. 

An example RAV system. Figure 3 
shows a RAV concept example: the F-8 


DFBW/RAV flight system. 1 This system 
involves the highly instrumented F-8 
DFBW research aircraft, a receiver for 
downlink telemetry, a transmitter for 
uplink telemetry, and a ground-based dig¬ 
ital computer for control-law computa- 
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tion. The ground-based computer receives 
pilot inputs and aircraft response 
parameters from the downlink telemetry. 
The control-law algorithms—pro¬ 
grammed in Fortran in the ground-based 
computer—are executed, and the resulting 
command outputs are uplinked to the air¬ 
craft. The uplinked commands are then 
interfaced to the on-board control system 
as required. 

The simulation facility contains a 
decommissioned F-8 aircraft (called an 
iron bird) and many DFBW flight system 
elements. The iron bird can be operated 
using actual triply redundant flight- 
control computers and triply redundant 
hydraulics. Figure 4 shows the F-8 iron 
bird simulation. The overall F-8 
DFBW/RAV system configuration was 
developed, verified, and validated using 
this simulation. 

The control surface (aileron, elevator, 
and rudder) positions are entered into the 
nonlinear equations of motion and the F-8 



Figure 4. Iron-bird simulation of F-8 digital fly-by-wire RAV. 
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Figure 5. Ground-based auxiliary computation facility for rapid prototyping 
advanced systems concepts. 


aerodynamic model in the simulation com¬ 
puter. The simulation computer also con¬ 
trols the cockpit instruments and models 
the aircraft sensors for input into the 
flight-control computers. The RAV 
ground computers are used as elements of 
the total simulation, and the uplink and 
downlink hardware interfaces are modeled 
in the simulation computer. The ground 
and on-board software interfaces in the 
simulation are identical to those of actual 
aircraft and ground facilities used in flight. 
The software developed and validated in 
the simulator is used without modification 
during RAV flight operations. 

The basic RAV facility was extended by 
using ground tracking radar and scenario 
simulations for the F-8 optimal trajectory 
research experiment program. This pro¬ 
gram’s goal was to demonstrate, in flight, 
an algorithm to solve the three- 
dimensional optimal interception of a 
maneuvering target. 

In preparation for flight research, two 
problems were immediately identified: the 
lack of appropriate navigation sensors on 
the F-8 aircraft and the need for repeata¬ 
ble data. To solve these problems, ground- 
based tracking radar and a synthetically 
generated target were used. The synthetic 
target’s trajectory was generated in the 
ground-based auxiliary computers in coor¬ 
dinates relative to the F-8 aircraft’s posi¬ 
tion. The ground-based radar supple¬ 
mented the lack of inertial (space position¬ 
ing) data from the F-8 system. Within the 
ground computers, relative position infor¬ 
mation from the synthetic target genera¬ 
tor was fed into the interception 
algorithm. The synthetic target provided 
repeatable data not obtainable using an 
actual target aircraft and allowed in-flight 
on-board radar simulation. The tracking 
radar allowed in-flight inertial-system 
simulation. 

One of the most significant lessons 
learned in this program was the impor¬ 
tance of integrating flight testing concerns 
in early human-machine interface develop¬ 
ment. The trajectory display for this pro¬ 
gram was originally developed in 
simulators and evaluated by experienced 
pilots at the NASA Langley Research Cen¬ 
ter. At that time, no flight-test program 
was expected. The pilots found both the 
display algorithm and the format accept¬ 
able. Later, when this display was evalu¬ 
ated by pilots at Ames-Dryden who were 
being asked to fly research experiments 
based on the optimal-interception algo¬ 
rithm, the display algorithm and format 
were deemed completely unacceptable. 


The display modifications required a sig¬ 
nificant effort representing the greatest 
investment in shifting from simulation to 
flight. The differences were reflected in the 
pilots’ perceptions, not in their abilities. 
Evaluating a system in a simulation 
involves a different mind-set than does the 
simulation evaluation of a flight system. 

Extending the RAV 
facility for rapid 
prototyping KBS 
concepts 

The RAV facility is being enhanced to 
accommodate flight research in advanced 
systems concepts including knowledge- 
based elements and modifications to 

(1) the NASA Highly Integrated Digi¬ 
tal Electronic Control (HIDEC) 
F-15 aircraft (to accept uplinked 
flight control and engine 
commands) 

(2) the ground-based auxiliary compu¬ 
tation facility (to include a dis¬ 
tributed processing system of 
numeric and symbolic processors 
combined in a local area network 
using high-speed communications 
hardware and standard communi¬ 
cation protocols) 

(3) the simulation facility (to insure 


compatibility with the enhance¬ 
ments to the aircraft and auxiliary 
computation facility) 

The modifications and additions to the 
ground-based computational facility 
shown in Figure 5 are particularly interest¬ 
ing. This facility’s key feature is the inclu¬ 
sion of a LAN based on thick Ethernet and 
the transmission control protocol/Internet 
protocol. Using a standard interface not 
only provides a way to integrate multiple 
symbolic and conventional processors but 
also allows outside users to remotely 
develop applications and easily integrate 
their systems into the RPF for use in simu¬ 
lation and flight testing. 

Developing the RPF for flight research 
in advanced systems concepts is a mul¬ 
tiyear, multiphase program. The first 
phase of the program entailed developing 
an enhanced ground-based auxiliary com¬ 
putation facility, integrating that facility 
into the simulation facility, and demon¬ 
strating the system’s increased capabilities. 
This phase was completed in June 1988 
with the demonstration of a real-time, dis¬ 
tributed prototype of an automated flight- 
test management system. Successful com¬ 
pletion of this phase certified the enhance¬ 
ments and capabilities of the ground-based 
computational facility. 

Duke et al. described the automated 
flight-test management system that pro¬ 
vides a flight-test engineer with a set of 
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tools to aid in flight planning, execution, 
and monitoring. 10 Flight-test planning is 
accomplished by providing a user interface 
for entering a list of maneuvers and 
maneuver constraints, A KBS orders these 
maneuvers using rules that consider 
maneuver priority, energy management, 
test-range boundaries, and aircraft enve¬ 
lope limitations. The system is designed to 
execute these flight-test plans with either 
a simulator or an aircraft, using combined 
conventional and knowledge-based sys¬ 
tems to perform closed-loop guidance 
functions, range management, and 
maneuver quality monitoring. 

By focusing on a real-time simulation 
demonstration intended as a prelude to 
flight testing, many deficiencies of the 
original concepts of the automated flight- 
test management system became obvious. 
The development environment provided 
by a symbolic processor, while extremely 
capable and flexible, was shown to be 
inadequate for supporting a real-time user 
interface that operated in the 1-2 Hz range. 
The computational burden of using a 
development system in a real-time appli¬ 
cation was shown to exceed the capabili¬ 
ties of a symbolic processor for even a 
relatively simple task. While these limita¬ 
tions were suspected during the develop¬ 
ment process, no limitations were 
conclusively demonstrated until simula¬ 
tion. If flight had not been among the 
original system’s goals, it might have been 
easy to overlook the problems. 


T he second phase of the facility 
development is scheduled to be 
completed in mid-1989 with the 
demonstration of a knowledge-based 
autopilot for the HIDEC F-15, imple¬ 
mented using a rule-based paradigm. This 
knowledge-based autopilot, being devel¬ 
oped as part of a research program in the 
verification and validation of knowledge- 
based systems, 11 has been demonstrated 
using a nonlinear simulation and will 
employ the F-15 HIDEC, integrated into 
the overall rapid-prototyping facility. 
Completion of this phase depends on 
demonstrating the use of the distributed 
processing capability of the ground-based 
facility as part of a flight system. 

In addition to the modifications 
described above, future plans include 
using a research F-18 aircraft as well as 
developing an on-board auxiliary com¬ 
puter to be used either in conjunction with 
or in place of the ground-based auxiliary 
computation facility. □ 
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A communication network consists 
of several interconnected subsys¬ 
tems, including physical media, 
communication controllers, computing 
and switching facilities, software systems, 
and customer premise equipment. A net¬ 
work is usually described by its topology, 
the protocol suite that controls network 
resources, and the applications or commu¬ 
nication services it supports. 

We can study network design and be¬ 
havior in different ways. An analytical 
approach requires a precise and simplified 
mathematical model emphasizing a single 
behavioral aspect as a function of one sub¬ 
system parameter (for example, delay or 
throughput as a function of channel speed 
or a parameter in a media access control 
protocol). But this narrow focus prevents 
us from examining how the interaction of 
several subsystems affects performance. 

Simulation is more versatile. It permits 
arbitrary level of detail and complexity in 
modeling, and we can study the effect of 
simultaneous variations in several parame¬ 
ters. However, simulation is limited by the 
speed and memory size of the computing 
facility. Software complexity imposes 
another limit: A communication network 
can be seen as a distributed computing 
facility, which is difficult to simulate in a 
general way. 



Prototyping is superior 
to analysis and 
simulation for studying 
network design and 
behavior, but until now 
it has not been cost 
effective. 


By adding features of implementation, 
prototyping comes closer to reality than 
simulation, since software and hardware 
designs in the prototype can be used di¬ 
rectly in the real network. If the prototype 
has an adequate monitoring and control 
system, data from experiments performed 
on the prototype can help tune design para¬ 
meters and identify bottlenecks in the real 
network. 

Prototyping is seldom used, since it 
requires a rare and expensive mix of skills 


This article is dedicated to the memory of Didier 
Giralt, an initial participant in the project. 


and resources. To be cost effective, the 
Programmable Network Prototyping Sys¬ 
tem (PNPS) uses a collection of reusable 
hardware modules that implement generic 
communications functions such as trans¬ 
mission, reception, signal propagation, 
and pattern matching. These modules are 
interconnected and configured to emulate 
a variety of communication networks 
whose behavior can be monitored under 
different load conditions. The user speci¬ 
fies a network as a set of interacting com¬ 
ponents using available software tools. 
These tools are accessible within a proto¬ 
typing environment that includes a control 
system for configuring the hardware mod¬ 
ules and interconnecting them according 
to the component specifications. Previ¬ 
ously designed components are stored in a 
library and can be used to specify new 
networks. 

PNPS is designed to provide a prototyp¬ 
ing environment for communication net¬ 
works. However, some of the basic ideas— 
especially the modularity of hardware and 
software and the separation between speci¬ 
fication of the network as interacting 
components and its implementation on the 
hardware modules—can be useful in other 
contexts. We will provide an overview of 
the way PNPS is used to study a network 
and then describe the hardware modules 
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Figure 1. The PNPS hardware architecture. 


Figure 2. The channel emulator. 


and the prototyping environment. Finally, 
we discuss some future work. 

The design procedure 

Design and evaluation of a network 
using PNPS proceed in three phases: speci¬ 
fication, experiment, and analysis. In the 
first phase, the user specifies the network 
as a set of components, including how they 
interact. The most important components 
are the network topology, the set of proto¬ 
cols used at each node, the load generator 
or applications component, and the moni¬ 
toring component that specifies the data to 
be collected. At the end of this step, the 
various components are subject to consis¬ 
tency checks. For example, if the topology 
specifies three nodes, then protocols for 
each node must be defined. This helps the 
user guard against errors in network speci¬ 
fication. 

In the second phase, the control system 
is used to download the component speci¬ 
fications onto the hardware. The applica¬ 
tion is then run while network data is col¬ 
lected according to the specification of the 
monitoring component. 

In the third phase, the collected data is 
analyzed to produce some performance 
measures. These may suggest network 
redesign or tuning of some network para¬ 
meters for a desired application. We arrive 
at a final design through an iterative ap¬ 


proach of specification, experiment, and 
analysis. By gradually accumulating a li¬ 
brary of network components, users can 
increase productivity. 

PNPS hardware 
architecture 

As Figure 1 shows, the PNPS hardware 
has two parts: reusable hardware modules 
and the control and observation system. 
The hardware modules consist of a channel 
emulator and a collection of node emula¬ 
tors. The control and observation system is 
a communication network linking the 
hardware modules to a workstation and a 
file server. Software tools and configura¬ 
tion commands are used from the worksta¬ 
tion. The channel emulator can be config¬ 
ured to emulate various network topolo¬ 
gies with transmission rates of 10 megabits 
per second. Each node emulator consists of 
a network controller and either a host 
emulator or an Integrated Services Digital 
Network workstation. 1 The host emulator 
emulates a resource in a distributed com¬ 
puting environment; it implements higher 
layer protocols and generates traffic ac¬ 
cording to specified statistics or the trace 
of a real system. The ISDN workstation 
has voice and video equipment for study¬ 
ing voice and video services implemented 
over a network. The network controller 


provides the interface to the channel emu¬ 
lator and implements a variety of low-level 
protocols. 

The channel emulator. The channel 
emulator (CE) can be configured to emu¬ 
late any network topology, including 
buses, rings, radio networks, and trees. 1 It 
is implemented entirely in digital logic, 
presenting digital signals at the interface of 
each node, thereby eliminating the need 
for signal encoding and decoding. It com¬ 
prises four submodules: the tap blocks, the 
input-routing block, the delay cells, and 
the output-routing block (see Figure 2). 

A delay cell emulates the propagation 
delay between adjacent nodes in a net¬ 
work. It is equivalent to a programmable 
shift register. At 10 megabits per second, a 
one-bit delay corresponds to 20 meters of 
cable. The input-routing block is a one-to- 
many switching matrix connecting the 
output of a tap block to the input of any 
delay cell to propagate it to other nodes. 
The output-routing block is a many-to-one 
switching matrix. It ORs the outputs of 
several delay cells and feeds the resulting 
digital signal to the tap block of a node. 
The tap block is the node’s interface to the 
channel emulator. It can be configured so 
that the signals the node transmits and 
receives are handled in different ways. For 
example, in a unidirectional ring topology, 
the signal a node receives comes from one 
side of the tap block and the transmitted 
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signal is sent to the other side. In a bidirec¬ 
tional bus topology, the signal received by 
a node is the OR of signals from both sides 
of the tap block, and the transmitted signal 
is sent to both sides of the tap block. In this 
case a collision detection signal can also be 
generated in the tap block. 

All signals travel through the channel 
emulator in groups of three. One signal is 
for data, the second is used to indicate valid 
data, and the third can be used for out-of- 
band signaling. Faults and bit errors can be 
introduced, making it possible to evaluate 
recovery and error-correction schemes. 

A four-node version of the channel 
emulator is now operational. A VLSI chip 
set has also been fabricated and contains a 
tap block chip, a delay cell chip, a 16x16 
input-routing-block chip, and a 16x16 
output-routing-block chip. These chips are 
being used to build a larger version of the 
CE. 

The network controller. The network 
controller module can implement media 
access control (MAC) protocols and other 
protocols at the higher layers.' It also 
monitors the activities of the CE. Func¬ 
tionally, the network controller has four 
submodules: the MAC submodule, the 
reception submodule, the transmission 
submodule, and the network submodule. 
These can be identified in Figure 3 by 
noting the units of each submodule in the 
following description. 

The MAC submodule implements the 
functions of MAC protocols and records 
events of interest at that layer. It deter¬ 
mines when a packet is to be transmitted 
and whether a received packet is to be 
copied and sent to the higher protocol 
layer. The submodule consists of a pattern 
recognizer, an event-recording unit, and a 
finite-state-machine (FSM) control unit. 
The FSM is a programmable unit that 
coordinates the activities of the MAC 
submodule, the transmission submodule, 
and the reception submodule. The FSM 
operates synchronously at 10 megahertz. It 
can change state every clock cycle, either 
deterministically or in response to an ex¬ 
ternal event. This allows the FSM to make 
a decision within one bit time of the trans¬ 
mitted or received data stream, an essential 
feature for MAC protocol implementation. 
The FSM is limited to 128 states and 16 
inputs. 

The pattern recognizer compares the 
incoming bit stream with patterns stored in 
its own memory and indicates whether or 
not a match is found. The comparison starts 
automatically when valid data is on the 


Figure 3. The network controller. 


channel; two patterns of the same length 
are checked against the incoming data 
simultaneously. The event-recording unit 
records specified events that occur at the 
CE level. It has a 24-bit hardware clock 
and a 512-location FIFO. The FSM stores 
in the FIFO a byte corresponding to each 
event, together with a time stamp indicat¬ 
ing when that event occurred. The time 
stamp is generated by a hardware counter 
using a global time reference available at 
every node. 

The reception submodule handles the 
incoming bit stream from the CE. It con¬ 
sists of five units: the receive FIFO, the 
deserializer, the cyclic redundancy code 
(CRC) checker, the receive buffer, and the 
receive address generator. Incoming data 
is stored automatically in the receive FIFO. 
The deserializer is a shift register that 
deserializes the data and stores it in the 
receive buffer. The receive address gen¬ 
erator indicates to the deserializer which 
location in the buffer will hold the next 
word of incoming data. The CRC checker 
checks the incoming data as it is read from 
the receive FIFO. 


The transmission submodule is respon¬ 
sible for transmitting to the CE a serial bit 
stream, optionally followed by a CRC 
sequence. It consists of five units: a trans¬ 
mit buffer, a transmit address generator, a 
serializer, a CRC generator, and an output 
selector. Data to be transmitted is stored in 
the transmit buffer. The transmit address 
generator keeps track of the current byte 
being transmitted and the number of bytes 
left to transmit. The serializer is a shift 
register that serializes the data. The CRC 
generator computes the CRC sequence 
during transmission. The output selector 
determines what is transmitted on the CE; 
the output can come from the serializer or 
the receive FIFO, or it can be set to 0 or 1. 
If a node is transmitting a packet, the out¬ 
put comes from the transmit buffer; if the 
node is on a ring and is repeating data, the 
output comes from the receive FIFO. 

The network submodule consists of a 
Motorola 68020 microprocessor with 256 
kilobytes of local memory running under a 
real-time executive, VRTX. 2 VRTX sup¬ 
ports multitasking, event-driven priority- 
based scheduling, and intertask communi- 
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Figure 4. The ISDN workstation. 




Figure 5. The prototyping environ¬ 
ment. 


cation and synchronization. This submod¬ 
ule implements functions of the MAC layer 
that require computing or memory beyond 
the capacity of the FSM. For example, it 
can calculate the back-off probability of a 
carrier-sense multiple-access (CSMA) 
protocol. It can also implement some 
higher layer protocols. It communicates 
with the host emulator to facilitate data 
transfer and task coordination. Finally, this 
submodule records specified data about its 
own activity and forwards to the host 
emulator data recorded by the MAC sub- 
module. 

The first network controller was built 


using the wire-wrapping technique. Cur¬ 
rently, five additional network controllers, 
built on printed circuit boards, are opera¬ 
tional. 

The host emulator. The host emulator 
implements the higher layer protocols not 
implemented on the network controller. It 
also generates traffic according to speci¬ 
fied statistics or a trace to simulate a user, 
a resource, or an application on the net¬ 
work. It is responsible for copying data to 
and from the transmit and receive buffers 
of the network controller. It also monitors 
data generation and creates data structures 
that encapsulate the information associ¬ 
ated with a transaction (for example, 
packet transmission or reception, and ses¬ 
sion). 

Although the tasks mentioned above 
should be executed concurrently, a single 
processor operating in a multitasking envi¬ 
ronment can implement them all, since 
their real-time constraints are not critical. 
The host emulator is a Motorola 68010- 
based microprocessor board running 
VRTX. 

The ISDN workstation. The ISDN 
workstation has voice and video equip¬ 
ment for experimenting with voice and 
video services over a network. As Figure 4 
shows, it consists of a workstation, a voice 
submodule, a video submodule, and a di¬ 


rect-memory-access controller. The work¬ 
station is used to configure the other parts 
and to generate data traffic. The voice sub- 
module can generate and receive packet- 
ized voice. The video submodule has a 
similar function for packetized video. 
These three components connect to a DMA 
controller over a Multibus, which transfers 
data between them and the network con¬ 
troller. Four host emulators and two ISDN 
workstations are operational in our labora¬ 
tory. We are developing a protocol that in¬ 
tegrates voice and data traffic on a token 
ring. 1 

The control and observation system. 

The control and observation system con¬ 
figures the hardware modules, sends com¬ 
mands to control the evaluation session, 
and monitors the behavior of the proto¬ 
typed network under a given traffic load. It 
is the backbone of the prototyping environ¬ 
ment, providing the user with the means to 
specify a network, prototype it, and evalu¬ 
ate the design. 

The control and observation system is 
hierarchical. At the top are a workstation 
and a file server. These two units are used 
to specify network components, download 
them to the hardware, run an experiment, 
and collect and analyze monitoring data. 
They communicate with the second-level 
units through an Ethernet local area net¬ 
work. These units are clusters of node 
emulators. (Figure 1 does not show the 
clusters.) In each cluster, an MC68010 
microprocessor running Unix responds to 
the received commands by performing the 
required tasks. It communicates with the 
various node emulators in that cluster via a 
global memory on a Multibus. The third 
and last level of the hierarchy consists of 
the node emulators, since they take part in 
configuration and monitoring. 

To configure the node emulators, a 
command is sent from the workstation to 
the Unix processor of each cluster. The 
Unix processor sends to each host emula¬ 
tor a copy of the code that should run on it. 
Thus, the host emulator is ready upon re¬ 
ceiving the code, and it starts downloading 
the MC68020 in the network controller 
with the required code. When the down¬ 
loading is complete, the MC68020 is up 
and running VRTX. At this stage the 
MC68020 configures the rest of the net¬ 
work controller, including the FSM of the 
MAC submodule, and thereby completes 
the configuration of the node emulator. 

The ISDN workstations are connected 
directly to the Ethernet. Therefore, the 
CPU in each of them acts like the Unix 
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processor in a cluster. It is itself configured 
when booted. 

The channel emulator is configured in a 
slightly different way. It can be configured 
from one particular cluster that hosts the 
CE controller device. This device forwards 
data to the CE for the latter to configure 
itself. The necessary data is provided by 
the Unix processor in that cluster when it 
receives the appropriate command from 
the workstation. 

Collection of the monitoring data gener¬ 
ated by every node emulator follows the 
opposite direction. Each host emulator 
sends the recorded information to the Unix 
processor in its respective cluster. At that 
level the received information undergoes a 
first stage of processing and filtering. The 
summarized information is sent up to the 
workstation, where it is analyzed to com¬ 
plete the evaluation phase of the design. 
An important feature of the monitoring 
structure is that the user can select the 
different events to be recorded at the vari¬ 
ous levels on the basis of the performance 
measure to be evaluated. The monitoring 
system’s architecture resembles that of the 
Metric system developed at Xerox. 3 

Currently there are two clusters, each 
hosting two node emulators. The two clus¬ 
ters and the two ISDN workstations are 
connected to an Ethernet, along with the 
file server and workstation. Any of these 
workstations can be used for design, con¬ 
figuration, and monitoring. 


The prototyping 
environment 

As Figure 5 shows, the prototyping 
environment provides several software 
tools to help design, test, and analyze a 
network. The major tools are the CE speci¬ 
fication language, two high-level lan¬ 
guages (LIFP and RTAG), the system soft¬ 
ware language, the design evaluation tools, 
and the user interface. The C programming 
language also is used for development. 
With the CE specification language the 
user specifies the network topology imple¬ 
mented on the CE. With LIFP (Language 
for Implementing Fast Protocols) the user 
specifies a MAC protocol component 
implemented by the MAC submodule of 
the network controller. With RTAG (Real- 
Time Asynchronous Grammars) the user 
specifies protocol components above the 
MAC layer. 

The protocol components run on the 
host emulator and the network submodule 


of the network controller; the designer 
determines the division of labor between 
the two. The system software language is 
used to integrate the specified components, 
and the design evaluation tools handle data 
collection and analysis. The menu-driven 
user interface guides the user through these 
tools. 

The CE specification language. To 

configure the CE, we must specify the 
configuration of each of its submodules. 1 
The designer chooses the desired network 
topology and all relevant parameters (for 
example, neighboring nodes and propaga¬ 
tion delay between nodes). This informa¬ 
tion can be entered interactively or placed 
in a file that can be stored for later use. The 
CE specification language interpreter then 
checks the given information for consis¬ 
tency and configures the CE. Users of the 
language do not require a deep understand¬ 
ing of the CE hardware. 

LIFP. LIFP is used to program the net¬ 
work controller’s MAC submodule. 4 It is 
based on the model of a MAC protocol as 
a coupled finite-state machine that handles 
logically different functions, such as trans¬ 
mission and reception, in a manner similar 
to that described by Aggarwal, Barbara, 
and Meth. 5 LIFP’s syntax resembles that of 
the C programming language, and LIFP 
uses the C preprocessor to permit use of the 
#define and #include statements of C. 

A LIFP program has two parts: the dec¬ 
larations section and the process defini¬ 
tions. Three types of declarations are made 
in a LIFP program: The protocol statement 
identifies a LIFP program; the pattern 
statement assigns symbolic names to the 
patterns used by the pattern recognizer; the 
interrupt statement declares prioritized 
interrupts that the FSM sends to the 
MC68020. 

To distinguish the logical-state ma¬ 
chines defined in LIFP from the hardware 
FSM, a logical-state machine is called a 
process. A process definition consists of 
three parts: a state declaration, an event 
declaration, and a state transition state¬ 
ment. Every state in a process must be 
declared in a state declaration. An event 
declaration associates the occurrence of an 
event detectable by the FSM (for example, 
token arrival) with a symbolic event name 
used by the monitoring software. A state 
transition statement gives the transition 
information for a single state of a process. 
It is one long If-Then-Else statement of the 
form If Boolean-expression Then Goto- 
statement, variable-assignment, variable- 


assignment, ... Else If ... Else .... Here, a 
Boolean expression is composed of terms 
and operators; a term can be either an input 
to the FSM or the state of another process. 
The operators are NOT, AND, OR. Proc¬ 
esses are coupled by making a transition of 
one process depend on the state of another. 
The Goto statement indicates the next state 
of the process if the associated expression 
is true. Variable assignments give values 
to the outputs of the FSM in that next state. 
There are two types of variables: A 
Boolean variable takes the value “true” or 
“false” and controls one FSM output; an 
aggregate variable has its own set of pos¬ 
sible values that control a number of out¬ 
puts. 

The lexical analyzer and the parser of 
the LIFP compiler were constructed using 
the Unix tools Lex and Yacc, respec¬ 
tively. 6 ’ 7 The compiler produces two out¬ 
put files: a configuration file and a debug¬ 
ging file. The configuration file is used to 
specify the contents of the pattern recog¬ 
nizer memory, the FSM memory, and the 
interrupt vector table of the MC68020. The 
compiler determines the contents of the 
FSM by taking the cross product of the 
various processes and removing the un¬ 
reachable global states. The FSM has a 
limit of 128 states. 

To debug a LIFP program, LIFPDB is 
used. It simulates the hardware modules 
and allows the user to single step and set 
break points in a LIFP program to observe 
data flowing through the modules from the 
buffers to the CE and vice versa. LIFPDB 
uses the compiler-created debugging file 
as input. 

The carrier-sense multiple-access/colli¬ 
sion-detection (CSMA/CD) and token- 
passing-ring protocols have been imple¬ 
mented at the MAC layer using LIFP. 
Currently, other MAC protocols are being 
specified in LIFP, but the 128-state limit 
on the FSM requires a simplification of 
these protocols. 

RTAG. RTAG is a formal specification 
language for protocols. 8 It supports struc¬ 
tured protocol design by allowing a proto¬ 
col to be decomposed into separately speci¬ 
fied serial and concurrent subprotocols. 
RTAG addresses event ordering, real-time 
constraints, and data dependence; it does 
not address the specification of packet 
formatting. 

An RTAG specification is based on a 
context-free grammar in which the produc¬ 
tions of the grammar correspond to control 
actions made by the protocol. Most of the 
terminal symbols correspond to message 
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Figure 6. The main menu. 



Figure 7. The LIFP window. 


events. These symbols are called input or 
output symbols, depending on whether the 
message is received or sent by the protocol 
entity being specified. 


Each RTAG symbol has an associated 
set of attributes, which in each symbol 
instance are instantiated with data values. 
The attributes of an input or output symbol 


correspond to the fields of the associated 
message. A Boolean expression can be 
associated with a production to act as an 
enabling condition. The Boolean expres¬ 
sion consists of attribute values that must 
be true for the production to be applied. A 
production can also have a set of attribute 
assignments that are performed when the 
production is applied. 

Each grammar symbol can be thought of 
as representing a subprotocol consisting of 
the event sequences it can generate. Pro¬ 
ductions can compose subprotocols in 
sequence or in parallel. In the first case the 
events derived by a subprotocol must pre¬ 
cede in real time the events of the subse¬ 
quent subprotocols, whereas in the second 
case the event sequences can be inter¬ 
leaved. Real-time constraints, such as 
time-outs, can be represented in RTAG 
using a special terminal symbol that has an 
attribute representing the length of a time 
interval. 

The RTAG parser is a program that 
implements a protocol given an RTAG 
specification. The parser processes input 
events and handles timers. Output symbols 
are handled by executing an “action rou¬ 
tine” named in the specification. These 
action routines are written in C. 

Currently, an RTAG parser has been 
integrated into the kernel of the Unix 4.2 
BSD operating system and the VRTX real¬ 
time executive. Thus, the host emulators, 
the ISDN workstations, and the network 
controllers can implement protocols speci¬ 
fied using RTAG. 

The system software language. Once 
the various components of a proposed 
network have been defined, the system 
software language is used to combine them 
to specify the software running on a net¬ 
work during an experiment.' This software 
includes statements to select the CE con¬ 
figuration, the various protocols used on 
each node, and the applications or traffic 
generation components. 

Two schemes are used for traffic genera¬ 
tion: one is to use a trace of events recorded 
on a real system; the other generates traffic 
according to a specified statistical profile. 
Parameters such as type of packet gener¬ 
ated, packet size, and packet inter-arrival 
time characterize the load. These parame¬ 
ters are chosen to model a particular appli¬ 
cation. 

Design evaluation tools. There are two 
design evaluation tools: the data collection 
language and the data analysis module.' 
The designer uses the data collection lan- 
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gliage to specify what data is to be col¬ 
lected before an experiment, and the data 
analysis module to analyze data after an 
experiment. 

While writing the individual software 
components, the designer must include 
calls to monitoring routines for events that 
may be of interest. Examples of important 
events recorded in each protocol are trans¬ 
mission requests and reception indica¬ 
tions. During an experiment, events may 
be too numerous for all to be stored. After 
specifying the components of an experi¬ 
ment with the system software language, 
the events to be stored must actually be 
chosen using the data collection language. 
The other events are filtered by the Unix 
processor. This can be done either by speci¬ 
fying the events explicitly or by deciding 
what measures are to be used for an experi¬ 
ment. In the latter approach, the data col¬ 
lection interpreter determines all the nec¬ 
essary events to collect and informs the 
user if the software components have not 
been written to collect these events. 

Running an experiment results in a large 
collection of data. The data analysis mod¬ 
ule comprises a number of routines that 
compute various performance measures 
such as packet delay, throughput, and 
queue length. It is based on AT&T’s S, 9 
a powerful, well-supported statistical 
package. 

The user interface. Designing a com¬ 
munication network and prototyping it on 
PNPS from scratch is difficult because it 
requires knowing about many different 
levels of protocols, the Use of the various 
specification languages previously dis¬ 
cussed, and even specific characteristics of 
the reusable hardware modules. A menu- 
driven user interface minimizes the effort 
and memorization required of the user and 
facilitates reuse of previously designed 
network components. 1 

The user starts the PNPS user interface, 
and the menu shown in Figure 6 appears. It 
offers four options: components design, 
experiment specification, experiment con¬ 
trol, and data analysis. The user selects the 
appropriate option with a mouse and then 
works with the tools associated with that 
option. 

In component design, the user can de¬ 
sign a new CE configuration, a LIFP pro¬ 
gram, an RTAG program, or a C program. 
These components are then added to a 
library for later use. While working on a 
LIFP program, for example, the user works 
on a window like the one in Figure 7. The 
buttons for the LIFP compiler and debug- 
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ing. If this kind of future appeals 
to you, we urge you to investi¬ 
gate a career with IDA. Please 
forward your resume to: 

Mr. Thomas J. Shirhall 
Manager of Professional Staffing 
Institute for Defense Analyses 
1801 N. Beauregard Street 
Alexandria, VA 22311 
An equal opportunity employer. 
U.S. Citizenship is required. 
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Figure 8. The data analysis menus. 


ger invoke these programs on the current 
file. Windows for working on a CE con¬ 
figuration, an RTAG program, or a C pro¬ 
gram are similar. 

In experiment design, the user combines 
components from the library with the sys¬ 
tem software language and chooses the 
data to be collected. Experiment control 
provides tools for downloading, running, 
and debugging experiments. 

Finally, data analysis is used to analyze 
data from experiments. Here the user inter¬ 
face is particularly useful. Over 30 data 
analysis routines have been written using 
S, as mentioned earlier. With the user in¬ 
terface, a user selects a data analysis rou¬ 
tine using a walking menu, as in Figure 8. 
The resulting graphs are then plotted on a 
separate viewing surface (Figure 9). 

Since many components exist, a help 
facility and a search facility are provided 
to manage them. The help facility directs 


the user through the various system tools, 
and the search facility allows the user to 
search for components by name, author, 
and keywords. These facilities are avail¬ 
able when the system is invoked. In Fig¬ 
ures 8 and 9, they are iconified. 


W e have four host emulators and 
two ISDN workstations opera¬ 
tional in PNPS, and we are 
beginning to implement a number of lower 
level protocols. During development we 
have gained a greater understanding of the 
impact of buffer management schemes, 
task scheduling, and interrupt priority as¬ 
signment on the real-time performance of 
protocols. 

We expect the rapid prototyping ap¬ 
proach to be especially effective in design¬ 
ing, evaluating, and tuning new protocols 
whose real-time performance and quality 


of service are difficult to determine ana¬ 
lytically, such as those that integrate voice 
and data. We are developing an integrated 
local area network for voice and data based 
on a token-passing ring. 1 In addition, we 
plan to study internetworking by evaluat¬ 
ing various gateway configurations. Al¬ 
though the data obtained by using PNPS is 
Specific to our particular hardware facility, 
the lessons learned can be applied to other 
systems. □ 
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Preface: In late February 1987, An Wang announced that he would no longer finance the Wang Institute of Graduate Studies, which 
he founded in 1979. Under the terms of a merger arranged with Boston University, the institute’s flagship degree—master of soft¬ 
ware engineering— was discontinued. As the end of another academic year approaches, the first in which no MSEs will be awarded 
by the institute, W. M. McKeeman reminds us of the program’s meaning and value to the software engineering profession. McKee- 

man, a professor at Wang Institute during its eight-year existence and currently with Digital Equipment Corporation, delivered the 

talk printed below on August 27, 1988, graduation day for the institute’s last six MSEs. 



G ood Evening. You may recall 
that last year Wang Institute pre¬ 
pared degrees for a few students 
who had not yet met the requirements but 
could do so through courses taken at Bos¬ 
ton University. Today, that foresight cul¬ 
minates in the graduation of six more 
masters of software engineering. I am here 
to explain a little of what that signifies. 

First, let me list the sources of my var¬ 
ied viewpoints on software engineering. At 
different times during the last decade I 
have been an academic advisor to Wang 
Institute and an administrator and teacher 
at the institute. I am just finishing a year 
of full-time research in conjunction with 
a Wang Institute student, and I will soon 
be programming full-time with Wang 
Institute graduates. Be prepared to shift 
viewpoints with me during the next few 
minutes. 

The history of the Wang Institute 
adventure is rich with complexities, but it 
simplifies to one idea: better software. To 
name the discipline of software engineer¬ 
ing is not to define it. There are, however, 
some distinguishing criteria. The foremost 
criterion is proficiency. It may be possible 
to beat a computer program into shape, 
but that is not economical. What a soft¬ 
ware engineer brings to the job is a tech- 
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nology for steady progress toward 
completed products: knowing what to do, 
when to do it, and how to get it done. 
Another criterion is personal discipline. 
Computer code that is not thoroughly 
understood by its programmer is not yet 
complete. If put into use, it leaves a legacy 
of trouble and disappointment for others. 
Software engineers are committed to get¬ 
ting the code right the first time. And we 
need knowledge and creativity. A software 
engineer knows a lot about the world and 
is willing to find new ways to integrate that 
knowledge into computational devices. 
One good idea is worth 1,000 man-hours, 
and ideas don’t cost anything at all. 

Since this seventh graduation marks the 
end of an era in software engineering edu¬ 
cation, I thought we might look to the 
immediate future. To do that, I invite you 
to the first regional meeting of the Society 
for Software Engineering. The meeting 
will be conducted by the chair of the local 
group. Please excuse me for a moment 
while I change hats. 



I call the first meeting of the Merrimac 
Valley Chapter of the SSE to order. 
The purpose of our organization is to 
further the practice of software engineer¬ 
ing. Membership is by invitation. Each 
meeting consists of a short technical 
presentation by a member and a longer dis¬ 
cussion by the membership. 

As the first order of business, I propose 
the invitation into membership of the aca¬ 
demic advisors, faculty, and graduates of 
the Wang Institute MSE program, [pause] 
Hearing no dissent, 1 declare the vote 
unanimous. There are now 162 members. 

The next order of business is today’s 
talk. Anything produced by man has 
faults. The idea of a technical review is to 
get capable outsiders to find those faults 
before the ultimate users have to deal with 


them. The method is to get the reviewers 
together in a room and go over the prod¬ 
uct, line by line and feature by feature. 
One could do this with just about any¬ 
thing; it is not applicable to software only. 
In any case, troubles are reported back to 
the working software engineer for analy¬ 
sis and fixes as necessary. 

A review takes a lot of good people a lot 
of time; it is expensive; it is often a trying 
experience. It is part of software engineer¬ 
ing proficiency to do reviews well. Our 
speaker today is known to you. He is soon 
to join the Technical Languages and Envi¬ 
ronments Group at Digital. He will talk 
about an interesting training device they 
are building at the Software Engineering 
Institute at Carnegie Mellon University. 
Excuse me for a moment while I change 
hats once again. 



B ecause SEI wants a way to train 
programmers to do a good job in 
technical reviews, it has built an 
experimental trainer on a fancy graphics 
workstation. I am going to tell you what 
I saw and what I think could be done. First 
let me set the scene. 

You are in a small conference room, 
looking across a table at several strangers. 
There is a lot of talk going on, and all par¬ 
ticipants are shuffling through stacks of 
paper in front of them. This is the review 
team getting ready to go to work, and you 
are one of them. 

The thing is, the table and papers and all 
the other people are on a color graphics 
workstation screen. You are sitting at the 
keyboard. The bottom part of the screen 
keeps track of what is going on and what 
you do during the training session. 

The roles of the review team are the 
moderator, the presenter, and two 
reviewers. You get to choose which role to 
play yourself. The other three roles acquire 


names and faces and voices and personal¬ 
ities, and are played by the computer. 
After a few moments to get used to the 
setup, the sights and sounds are natural 
enough that you forget the trappings and 
can “get into” your role. When one of the 
other reviewers speaks to you, that face 
looks right at you. Usually the other faces 
look left or right toward the speaker on the 
screen. When it is your turn to talk, they 
all look at you. You do not get to talk, 
however. A menu of eight or so responses 
appears, and you choose one by keystroke. 
Suppose one of the others has just said 
something and it is your turn to talk. You 
need to push a key. Maybe you push the 
one for “say nothing.” Or maybe you 
push the one for an aggressive comment 
like, “That’s a stupid remark.” Or maybe 
you are more diplomatic and say, “1 think 
there may be a better way to look at this. ’ ’ 
Whatever you choose, the training system 
responds and the review proceeds toward 
a conclusion. 

The people across the table react to you 
and the situation with anger, boredom, 
patience, or any of a catalog of human 
responses. You do, too. There are sur¬ 
prises. Perhaps it is your turn to speak and 
one of the faces is scowling down at the pile 
of papers instead of looking at you. 
Among your possible responses you may 
find “John! I am waiting for your atten¬ 
tion.” As you may guess, things can 
quickly get out of hand. 

There are two kinds of things to learn 
from this trainer. The first is standard stuff 
about reviews: who is involved, how to 
organize the review, what to look for, and 
what to report. The second part concerns 
the messy business of finding fault with a 
colleague’s work and saying so. 

There isn’t any explicit teaching going 
on; one learns by doing. You may run into 
a filibuster. Or there may be an attacker, 
a defender, a problem solver, a needier, a 
showoff, a shrinking violet, or some other 
kind of bad review behavior. Part of profi¬ 
ciency is being able to deal with whatever 
comes up and still carry out the review. 

1 like this trainer. One does not have to 
actually offend someone to find out what 
happens. After you have tried something 
and think you know enough about how it 
went, you can back up the simulation as 
many steps as you like and try a different 
tack. You can switch roles at any moment. 
The simulation can be randomized so that 
each session is different. There can be a 
printed transcript of your session together 
with a computer-graded analysis of how it 
went. There is an opportunity to customize 
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the simulation for your work environment 
and objectives. And, finally, as the tech¬ 
nology of technical reviews improves, the 
authors of the simulation can embed 
advances in the next release of the trainer 
for a painless form of technology injec¬ 
tion. That’s all I have to say. If you want 
to know more about this trainer, the con¬ 
tact Is Scott Stevens of SEI. I’ll turn the 
meeting back over to the chair. 

O n behalf of the membership of 
the Merrimack SSE, I thank you 
for being our guests. There will 
be refreshments and an opportunity for 



discussion later. Members will be notified 
of the time and place of the next meeting. 
Excuse me for a moment as I change hats 
for the last time. 

M ore than 20 years ago, Fred 
Brooks was responsible for 
one of the most massive soft¬ 
ware systems ever built. Last year he wrote 
that there are not going to be any silver 
bullets in the software business—no grand 
breakthroughs. Progress will come in the 
trenches, a few percentage points at a time. 
I expect the SSE to be at the forefront. For 
every Michelangelo with a hammer and a 
chisel, there are a dozen people with 
000-grade sandpaper. They won’t all be 
famous because there isn’t enough fame to 
go around. But they will get the job done, 
and we will be glad they did. 

There is one thing we know about the six 
software engineers graduating today. They 
have grit. They got their degrees in the face 
of unexpected obstacles. As each degree is 
awarded, I will be thinking about the per¬ 
sonal story behind it. All these graduates 
were on The Last Project, a Wang Insti¬ 
tute course conducted here under the 
auspices of Boston University. The team 
was given a hard task, they divided up the 


work, and they got it done. The starting 
point was a compiler that was working but 
almost untried and certainly untested. 
When they came up against new problems, 
they looked up solutions in the literature. 
And through it all they argued with each 
other and with management, making their 
opinions known and finally finding ways 
to make them count. It was marvelous to 
watch. They have earned their degrees. 
Now they are members of the Society of 
Software Engineers. I congratulate them. 

Postscript: On November 7, 1988, approx¬ 
imately 60 alumni met at Boston Univer¬ 
sity’s Corporate Education Center 
(formerly the site of the Wang Institute) in 
Tyngsboro, Massachusetts. Most atten¬ 
dees agreed to continue regular meetings 
under the banner of the SSE, and a small 
group is putting together the mechanics of 
the chapter. The proposed SSE bylaws and 
charter were distributed for review at the 
first regular meeting, held April 5, 1989. 
A t the meeting, Gary Pollice, who kept a 
diary during the development of the Sun 
386i compiler, talked on “The Develop¬ 
ment Diary as a Software Engineering 
Artifact—Experiences and Lessons 
Learned. ”□ 


IEEE INFOCOM 
The Conference on Computer Communications 



The Ninth Annual Joint Conference 
of the IEEE Computer and Communications Societies 

June 5 - 7,1990, Hotel Nikko, San Francisco, California 

Sponsored by the Technical Committees for Computer Communications of the Societies 


THE MULTIPLE FACETS OF INTEGRATION 


Schedule: 


Submit papers to: 


I IEEE COMPUTER SOCIETY 


THE INSTITUTE OF ELECTRICAL AND 
ELECTRONICS ENGINEERS, INC. 


5 copies of Full Paper: August 31,1989 

Notification of Acceptance: January 1,1990 

Camera Ready Copy: February 15,1990 

Conference: June 5-7,1990 

Tutorials: June 3-4,1990 


Prof. M. Gerla, Technical Program Chairman 
IEEE INFOCOM'90 


Dept, of Computer Science 
UCLA - BH 3732H 
Los Angeles, CA 90024 
Phone: (213) 825-2660 


IEEE Communications Society 











im Haynes, Computer Center, UC Santa Cruz, CA 95065 
Bitnet, haynes@ucscc; Arpa, haynes@ucscc.ucsc.edu 


“Software engineering” vs. software engineering 


Robert L. Baber, software engineer 

As a software developer of long stand¬ 
ing (30-plus years), I subscribe to and 
fully support the transition of our field 
from an art/craft/trade to an engineering 
discipline. However, as an engineer 
(electrical) by education, I deeply resent 
the misuse of the word “engineering” in 
the compound term “software engineer¬ 
ing.” Such misuse constitutes, in my 
opinion, a cheap, deceptive attempt to 
take advantage of the professional 
reputation and image developed by real 
engineers over a century or so without 
acquiring a comparable level of profes¬ 
sional knowledge, qualification, and ca¬ 
pability. In short, it constitutes theft of 
professional reputation. 

What does “software engineering” 
mean today? The term commonly refers 
to a certain collection of ideas and views 
regarding the software development 
process and relevant management prin¬ 
ciples. Most literature on the subject 
covers topics such as the software life 
cycle, design procedures and tools, user- 
developer interaction, specifying soft¬ 
ware systems, organizing documentation, 
estimating development cost and time, 
and project planning and management. 
Useful as this material may be, it does 
not in any way capture the essence of en¬ 
gineering; it would not be recognized by 
engineers in the classical fields as “engi¬ 
neering.” 

What does the term “engineering” re¬ 
ally mean? The application of scientific 
knowledge and principles to the task of 
designing and constructing a device, ma¬ 
chine, or system of economic value is 
probably the most characteristic aspect 
of engineering. Especially noteworthy is 
that the engineer employs a scientific, 
theoretical foundation to verify — by 
systematic calculation and before the ob¬ 
ject is actually built — that a proposed 
design will satisfy the specifications. 

Thus, the terms “software engineer¬ 
ing” as typically used in the literature 
and “engineering” as understood by real 
engineers have nothing in common. They 
refer to quite different aspects of their re¬ 
spective fields. In other words, “software 


engineering” as outlined above is not 
engineering; it is better described as 
“software development management,” 
perhaps even “software engineering man¬ 
agement.” If one insists on a more im¬ 
pressive buzz word, I suggest something 
like “Integrated Software Life Cycle 
Management” (ISLCM). 

Several recent discussions with engi¬ 
neer acquaintances made it painfully 
clear to me that a significant number of 


We deceive ourselves into 
believing that software 
engineering will bring 
our software to the same 
level of reliability and 
quality as that achieved 
in the classical 
engineering fields. 


true engineers do not take us and our 
claims to be “engineers” very seriously. 
Our misuse of the word “engineering” 
leads them to conclude that we do not 
understand what engineering is really all 
about. Their attitude toward us as would- 
be professionals seems to be in transition 
from sceptical scorn to rational rejection. 
If our misuse of the term “engineering” 
continues and grows, our true engineer¬ 
ing brethren will, sooner or later, feel 


compelled to isolate us from their midst 
to protect their hard-earned professional 
reputation and image. They cannot afford 
to allow that reputation to be damaged 
by terminological association with us 
and our buggy software. Such isolation 
would be unfortunate for both groups, 
but more so for us. 

Another unfortunate consequence of 
our misuse of the term “engineering” is 
that we deceive ourselves into believing 
that the kit bag we call “software engi¬ 
neering” will bring our software to the 
same level of reliability and quality as 
that long since achieved in the classical 
engineering fields. But just calling some¬ 
thing “engineering” does not make it en¬ 
gineering. Engineers in other fields did 
not achieve their impressive technical re¬ 
sults by employing ideas, approaches, 
and methods corresponding to those 
comprising our “software engineering,” 
and there is no convincing evidence that 
these will do the trick for software, ei¬ 
ther. Success in classical engineering de¬ 
rives from a thorough understanding of 
the scientific, theoretical, and mathe¬ 
matical foundations of the engineer’s 
field and an ability to apply this under¬ 
standing to practical problems. 

Software developr ent can and should 
be a true engineering discipline. Let’s 
not make the term “software engineer¬ 
ing” meaningless before this new field 
has had a chance to form and prove it¬ 
self. Instead, let’s buckle down and get 
started on the hard mental work neces¬ 
sary to turn our field into a real engineer¬ 
ing discipline. 


“The Open Channel" is exactly what the name implies: a forum for the free ex¬ 
change of technical ideas. Try to hold your contributions to one page maximum 
in the final magazine format (about 1,000 words). 

We'll accept anything (short of libel or obscenity) sb long as it's submitted by 
a member of the IEEE Computer Society. If it's really bizarre, we may ask you to 
get another member to cosponsor your item. 

Send everything to Jim Haynes at the address given above. 
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UPDATE 


NSF launches software 

The National Science Foundation has 
launched an experimental software capi¬ 
talization initiative to support investiga¬ 
tors by raising the base level of software 
available to the research community, ac¬ 
cording to William Wulf, assistant direc¬ 
tor of the NSF’s CISE Directorate. 

CISE programs will provide funds for 
purchasing software from vendors, pol¬ 
ishing and distributing the software re¬ 
sults of previous research efforts, and 
hiring research support staff for implem¬ 
entation efforts, Wulf said. 

The initiative requires grantees to 
make source code and documentation 
available for academic and commercial 
research. Commercial rights to software 
are governed by the grantees’ institu¬ 
tional rules, as is customary for NSF 
grants. CISE will not support reimple¬ 
mentation of existing products or com¬ 
petition with vendors. 

Under the initiative, a grant’s budget 
should list as equipment the costs of pur¬ 
chasing software packages or source li¬ 
cense agreements. 

Initiative guidelines permit repackag- 


initiative 

ing of research software for use by other 
investigators. They also support hiring 
research support staff where needed to 
complete software development. 

Supplements for purchasing or pack¬ 
aging software will range up to $20,000, 
said Wulf. Grant proposals to implement 
software will range up to $100,000. 

Grant proposals must assess alterna¬ 
tives, present development plans that in¬ 
clude maintenance, and provide source 
code and documentation for a nominal 
distribution fee (less than $300). Propos¬ 
als should cite investigators who will 
benefit from software enhancements, 
identify parts of the software usable in 
other implementations, and describe the 
investigators’ previous software devel¬ 
opment efforts. 

CISE invites your response to help it 
decide whether to continue or expand 
the initiative. Contact a CISE program 
director or William Wulf, Assistant Di¬ 
rector, CISE Directorate, National Sci¬ 
ence Foundation, 1800 G St., Washing¬ 
ton, DC 20550. Wulf’s electronic mail 
address is wwulf@note.nsf.gov. 


Computer mouse 
inventor gets funding 

Douglas Engelbart, who invented the 
computer mouse at Stanford Research 
Institute in 1965, has obtained initial 
support for his Project Bootstrap. Engel¬ 
bart believes that an organization can 
boost its own effectiveness - pull itself 
up by its own bootstraps - by the right 
mix of computer tools, work methods, 
and organizational structure. 

Project Bootstrap involves multidisci¬ 
plinary, multicorporate collaboration. It 
aims to create an environment for inte¬ 
grating the efforts of vendors, consult¬ 
ants, end-user organizations, and univer- 

Expected to cost about $400,000 in its 
first year, the project has received funds 
from the Kapor Family Foundation, 
established by Lotus founder Mitchell 
Kapor, Apple Computer, and Sun Micro¬ 
systems. 

Readers wishing more information on 
Project Bootstrap can contact Christina 
Engelbart at the Academic Information 
Resources office, phone (415) 725-2985. 


News briefs 


Program fosters parallel process¬ 
ing. The ARCH Development Corp. 
and the Advanced Computing Re¬ 
search Facility at the Dept, of En¬ 
ergy’s Argonne National Laboratory 
have created a program to bring to¬ 
gether users and manufacturers of par¬ 
allel-processing computers. The ACRF 
Industry Affiliate Program allows af¬ 
filiate members to spend one month at 
the facility to test their software on the 
facility’s parallel processing machines. 
Affiliate members also partcipate in 
classes, seminars, and workshops 
sponsored by the ACRF. 

Argonne National Laboratory is lo¬ 
cated at 9700 S. Cass Ave., Argonne, 
IL 60439. 


NSF selects Presidential Young 
Investigators. The National Science 
Foundation has selected 197 academic 
scientists and engineers to receive 
Presidential Young Investigator 
awards for 1989. The awards fund re¬ 
search by faculty members near the 
beginning of their careers. 

Each grant consists of annual base 
NSF funding of $25,000, plus match¬ 
ing funds up to $37,500 from NSF and 
the private sector. Award recipients 
can receive up to $100,000 a year for 
five years in a combination of federal 
and matching private funds. 

For more information on the 1989 
awardees, write to PYI Awards Pro¬ 
gram, Division of Research Career 
Development, Room 630, National 
Science Foundation, 1800 G St. NW, 
Washington, DC 20550. 


CMU creates doctorate in robot¬ 
ics. Carnegie Mellon University has 
created a doctoral program in robotics, 
operated by the university’s Robotics 
Institute, graduate schools of computer 
science and business, and college of 
engineering. Takeo Kanade directs the 
program, assisted by Steven A. Shafer. 

The curriculum will include basic 
robotic technologies such as percep¬ 
tion, cognition and manipulation, and 
integrated robot systems for manufac¬ 
turing automation. Students will ac¬ 
quire hands-on experience at physical 
levels of robotics and at decision¬ 
making levels in artificial intelligence. 

The first class, limited to eight stu¬ 
dents a year and increasing to 15 even¬ 
tually, will begin in the fall of 1989. 
Students in the program will receive a 
full tuition grant and living allowance. 
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Editor: Sallie Sheppard, Office of Associate Provost for Honors Program and Undergraduate Studies, Texas A&M University, College Station, TX 77843; (409) 845-3210 


First issue of Transactions on Knowledge and Data Engineering taking shape 


The first issue of IEEE Transactions 
on Knowledge and Data Engineering , 
delayed from its originally scheduled 
date of March until June due to diffi¬ 
culties in processing the large number of 
manuscripts from outside the US, will 
consist of contributions from several 
recognized researchers in the field. 

The present lineup of papers is as 
follows: 

• Introductions by former IEEE 
Computer Society Presidents Oscar 
Garcia, Roy Russo, and Ed Parrish, 
and incumbent President Ken 
Anderson. 

• An editorial entitled “Knowledge 
and Data Engineering” by Editor-in- 
Chief C. V. Ramamoorthy and Associ¬ 
ate Editor-in-Chief Ben Wah. 

• “A Personal Chronicle: Creating 
Better Information Systems, With Some 
Guiding Principles,” by Charles W. 
Bachman. 

• “Future Trends in Data Ba§e Sys¬ 
tems,” Michael Stonebraker. 

• “Heterogeneous Databases: 
Profilerations, Issues, and Solutions,” 
David K. Hsiao and Magdi N. Kamel. 

• “Towards Benchmarks for Knowl¬ 
edge Systems, and Their Applications 
for Data Engineering,” Frederick 
Hayes-Roth. 

• “Trends In Cooperative Distributed 
Problem Solving,” Edmund H. Durfee, 
Victor R. Lesser, and Daniel D. Corkill. 

• “Knowledge Representation in 
Fuzzy Logic,” Lotfi A. Zadeh. 

• “The Future of Expert Systems,” 
Douglas Lenat. 

• “The Impact of Optics on Data and 
Knowledge Base Systems,” P. Bruce 
Berra, Arif Ghafoor, Pericles A. 

Mitkas, Slawomir J. Marcinkowski, 
and Mohsen Guizani. 

• “A Review of Macsyma,” Richard 
J. Fateman. 

• “What You Always Wanted to 
Know About Datalog (and Never Dared 
to Ask),” S. Ceri, G. Gottlob, and L. 
Tanca. 

The second and third issues, which 
according to editors Ramamoorthy and 
Wah will follow closely on the heels of 
the first issue, will consist of con¬ 
tributed papers. The fourth issue, which 


the editors expect to appear before the 
end of the year, will consist of the best 
papers from the 1988 and 1989 Interna¬ 
tional Conferences on Data 
Engineering. 

Ramamoorthy and Wah report that 
over 160 submissions have been 
received thus far, and 10 Editorial 
Board members have been selected. 

The objective of IEEE TKDE is to 
provide an international interdiscipli- 


The IEEE Computer Society has 
announced the formation of the Task 
Force on Expert Systems Applications 
established to improve the capabilities 
of organizations and individuals in 
working with expert systems tech¬ 
nologies. 

The society’s Technical Activities 
Board authorized creation of the ESA 
task force at a March 2 meeting in San 
Francisco. The new task force is being 
organized under the direction of chair 
Dan Yurman, a member of the infor¬ 
mation management staff of the US 
Environmental Protection Agency’s 
Hazardous Waste Program. 

The task force will sponsor activities 
at national and international levels and 
will also support local events. On the 
national and international scale, it will 
publish a newsletter, exchange elec¬ 
tronic mail, provide speakers for con¬ 
ferences, organize tutorials and 
symposiums, and convene meetings on 
standards both on its own and in con¬ 
junction with other Computer Society 
entities. 

MIS and end users are experiencing 
an explosion of interest and activity in 
expert systems applications in almost al 
sectors of business, government, and 
education, Yurman said. This is taking 
place due to the wide distribution of 
expert system shells on personal com¬ 
puters and workstations. 

“This is a remarkable change in the 
field of artificial intelligence in which 


nary forum for publication of results on 
the research, design, and development 
of knowledge and data engineering 
methodologies, strategies, and systems. 
It will cover such areas as computer 
science, artificial intelligence, electrical 
engineering, computer engineering, and 
cognitive science. 

Subscription information is available 
from the Computer Society at (714) 
821-8380. 


developers usually rely on specialized 
computer platforms and programming 
languages,” Yurman said. 

Expert systems are the most mature 
and resilient products to emerge from 
the AI community, and they are being 
adopted by corporations and govern¬ 
ment departments to improve produc¬ 
tivity. Expert systems applications to 
specific knowledge intensive systems 
return high yields. Success stories for 
expert systems are more common today 
than they were two years ago. An esti¬ 
mated 2,000 operational expert systems 
are in current use, and 80 percent of 
them run on personal computers, Yur¬ 
man said. 

He said task force participants should 
derive great value from regular user 
group-like interaction. Expert systems 
applications are used in such broad 
areas as business (for example, banking 
and finance, manufacturing, and ser¬ 
vice functions), medical practice, 
government (including the military), 
and education. 

A number of people have agreed to 
serve on the task force’s steering com¬ 
mittee, including Laurel Kaleda of 
IBM, the Computer Society’s vice presi¬ 
dent for technical activities. 

Additional information can be 
obtained by calling Yurman at (202) 
475-6754, or by writing to TAB Coordi¬ 
nator, IEEE Computer Society, 1730 
Massachusetts Ave. NW, Washington, 
DC 20036-1903 


Computer Society establishes Task Force 
on Expert System Applications 
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NEWS FROM THE COMMITTEE ON PUBLIC POLICY 


Subcommittee chairs report on a variety of vital 


Ralph J. Preiss, COPP Chair 

Pauli. Davis, COPP Vice Chair 

The steering committee of the IEEE 
Computer Society’s Committee on Pub¬ 
lic Policy met during Compcon Spring 
89 in San Francisco February 27 to hear 
reports from subcommittee chairs on 
various areas of concern and planned 
activities. 

Reports were filed on the following 
matters: 

Transnational information exchange. 

The National Research Council- 
prepared report has finally been pub¬ 
lished. Sy Goodman chaired the com¬ 
mittee that drafted the 280-page report. 
Key COPP members will receive a copy 
for review. 

Interested society members may order 
copies of “Global Trends in Computer 
Technology and their Impact on Export 
Control” from Computer Science and 
Technology Board, National Research 
Council, 2101 Constitution Ave. NW, 
Washington, DC 20418. 

Technical expert directory. Ray 
Oberly reported that two technical 
expert directories are being discussed. A 
COPP directory is planned as a listing 
of experts and particulars placed in a 
computer database with controlled 
access and selection by COPP. The pur¬ 
pose is to have a set of experts available 
at COPP’s disposal who can be called 
to participate on short notice to draft 
public positions for the society. 

The second directory, which will be 
similar to the society’s volunteer direc¬ 
tory, is being prepared by the society’s 
Public Relations Committee. That com¬ 
mittee will assemble, control, and dis¬ 
tribute the latter directory. It will be 
made available as a public relations ser¬ 
vice for press inquiries on computer- 
related subject matter. 

Intellectual property protection. The 
Vernon-Tate lawsuit has shown how 
complicated copyright protection can 
get if not properly defined. From the 
subcommittee’s standpoint, it seems as 
though a company is trying to copyright 
a language. Lawyers are going to define 
how the vague law designed for 
copyrighting the written expression 
applies to programs and computer 
screens. 

It should be recalled that the US 
Copyright Office, in a June 1988 ruling 
in which it opted to ignore the Com¬ 
puter Society’s recommendation 


because “it would be difficult to 
administer,” simply passed the problem 
on to the courts without a resolution. 

In the meantime, the Computer Soci¬ 
ety Press has published “Protecting 
your Proprietary Rights in the Com¬ 
puter and High-Technology Indus¬ 
tries.” This may be ordered from the 
CS Press office in Los Alamitos, 
California, by calling (800) CS-BOOKS 
or (714) 821-8380 in California and 
specifying order No. 754. 

Foreign engineers. George Arnovick 
has become chair of this subcommittee. 
He plans to poll its members on their 
ideas to prepare society positions on the 
immigration law modifications cur¬ 
rently in Congressional committees. 

The subcommittee will also be mak¬ 
ing contact with education, govern¬ 
ment, and industry representatives on 
other typical issues involving foreign 
engineers. 

Ethics. While no chair has yet been 
found, this subcommittee has been busy 
coming up with a position paper on 
computer viruses. Over 50 people have 
participated in preparing various drafts. 

The main conclusion the subcommit¬ 
tee has drawn is that a computer virus 
causes software vandalism, which is a 
broader subject. There are no laws 
governing software vandalism. 

While the society can take a position 
that it is unethical and unprofessional 
to knowingly cause a computer virus 
attack, the society has no clout in 
enforcing its ethical position unless laws 
exist which also make such attacks 
criminal acts. 

The proposed call to action is for 
society experts to participate with legis¬ 
lative branches of government in defin¬ 
ing what constitutes software vandalism 
damage, acceptable evidence, location 
of the crime (especially from the juris¬ 
dictional basis), and who the culprit 
might be. Some very hard and interest¬ 
ing issues lie ahead. 

The draft of the position paper on 
software vandalism was presented to 
the society’s Board of Governors March 
3, and the board is expected to review it 
again at its mid-May meeting in 
Pittsburgh. 

Education/computer literacy. A need 
to address general public computer edu¬ 
cation issues in grades K-12, involving 


issues 


teachers, school boards, and local and 
state government officials, has been 
uncovered and will be pursued. Even on 
this matter, the concept of computer 
ethics will have to be made part of the 
education issue. 

Computing Research Board. Com¬ 
puter Society President Ken Anderson 
spoke to COPP on the new Computing 
Research Board that is now based at the 
society’s Washington, DC, office. The 
CRB is working toward establishing 
itself as the public policy representative 
speaking for the Computer Society, the 
Society for Industrial and Applied 
Mathematics, the ACM, independent 
computer research laboratories, and 
computer science and computer 
engineering PhD-granting institutions 
on the subject uf research in computing. 

Professional activities. Last Novem¬ 
ber, the IEEE United States Activities 
Board (USAB) established the PACE 
Divisional'Activities Committee as a 
committee of the Professional Activities 
Council for Engineers (PACE Council) 
of USAB. Some of the objectives and 
functions of the new Committee are to: 

(a) Encourage each society to estab¬ 
lish a professional activities body. 

(b) Ask each society to promote 
professional activities within its chap¬ 
ters in the sections by encouraging the 
chapters to appoint chapter profes¬ 
sional activities committee chair¬ 
persons. 

(c) Develop a network for soci¬ 
ety/chapter response to and action on 
critical USAB issues, in coordination 
with the USAB Technology Activities 
Council. 

USAB is providing funding for sup¬ 
port of professional activity projects 
originated within societies and chapters. 
Further information on how to partici¬ 
pate in these programs and how to pre¬ 
pare projects and apply for these funds 
is available by contacting Paul I. Davis, 
Division VIII coordinator for PACE, 
phone (614) 897-2331, ext. 2710; or 
James F. Strother, chair, PACE Divi¬ 
sion Activities Committee, and chair, 
NCAC Professional Activities Commit¬ 
tee, phone (703) 751-6186. 

The next COPP meeting was tenta¬ 
tively planned for mid-May at the soci¬ 
ety’s Washington, DC, office. 
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Editor: Helen M, Wood, National Oceanic and Atmospheric Administration, Rm. 1069, Federal Bldg. No. 4, Washington, DC 20233, phone (301) 763-1564. 


Sparc International takes over in directing Sparc standard 


Nancy Hays, Computer staff 

The Sparc Vendor Council has 
created a not-for-profit organization 
open to hardware and software vendors 
of Sparc products. Sparc International 
will further development and industry 
understanding of the Sparc standard, 
according to SVC spokesmen, and 
supersedes the SVC. 

Sun Microsystems introduced Sparc 
(scalable processor architecture) in 
1987. The company was a major sup¬ 
porter of the SVC and now actively sup¬ 
ports SI with its technical expertise. 

Key SI charter items include 

• Ensuring development and open 
availability of hardware and software 
technology needed to build Sparc 
systems. 

• Publishing binary compatibility 
specifications and instituting confor¬ 
mance testing. 

• Directing evolution of the Sparc 
architecture. 

• Promoting and supporting third- 
party systems and applications. 

• Providing a demonstration center 


for Sparc vendors. 

An SI spokesman said that the organ¬ 
ization considers itself a proponent of a 
truly open RISC standard because of 
the existence of multiple sources for 
Sparc chips and software development 
tools. More than 400 applications soft¬ 
ware packages are available as well. 

SI and AT&T’s Unix Software Oper¬ 
ation will jointly develop the Unix Sys¬ 
tem V Release 4.0 Applications Binary 
Interface for the Sparc architecture. 
AT&T and Sun Microsystems began 
this development project in October 
1987. 

SI was interviewing for a permanent 
chief executive officer at press time. 
Greg Leonard of Fujitsu Microelec¬ 
tronics served as the interim CEO for 
SI. The board of directors consists of 
representatives of the five SVC mem¬ 
bers (Bipolar Integrated Technology, 
Fujitsu Microelectronics, LSI Logic, 
Cypress Semiconductor, and Texas 
Instruments). 

At its April 7 meeting, the board 


finalized classes of membership, which 
will allow Sun and other interested com¬ 
panies and individuals to join SI. 
Executive membership for $100,000 
gives a company the right to seat a 
member on the board of directors and 
on the architecture committee. Associ¬ 
ate membership for $25,000 allows a 
company to participate in all commit¬ 
tees and seat a member on the board. 
Affiliate membership for $100 permits 
students, teachers, consultants, and 
other interested individuals to receive 
Si’s publications. 

Funding from the original five mem¬ 
bers and new members will support the 
new CEO and staff. According to 
Leonard, the first step is to put together 
a strategic plan. Once the basic steps 
have been taken, SI hopes to organize a 
Sparc conference. 

For more information, contact Sparc 
International at its mailing address, 801 
W. El Camino Real, Suite 167, Moun¬ 
tain View, CA 94040, phone (415) 
966-8718. 


X3, IEEE revising Pascal 

Pascal Computer Programming Lan¬ 
guage, ANSI/IEEE 770X3.97-1983, will 
be replaced by a revision of ISO 
7185-1983, Pascal, once the Joint Pas¬ 
cal Committee (JPC) (cosponsored by 
the IEEE and the Accredited Standards 
Committee) completes its work on the 
project. JPC expects to finish the revi- 


standard 

sion of ISO 7185 by this December. Its 
next meeting is scheduled June 6-9 in 
Portland, Oregon. 

JPC will work in cooperation with 
ISO/IEC JTC1/SC22/WG2 to bring 
the international and American stan¬ 
dards for Pascal into alignment. 

For more information, contact the 


chair of Technical Committee X3J9 
(Pascal), Thomas N. Turba, Unisys 
Corp., MS: WE3C, PO Box 64942, St. 
Paul, MN 55164, phone (612) 635-2349; 
or the chair of the IEEE Computer 
Society Working Group on Pascal, 
Michael Hagerty, 27911 Berwick Dr., 
Carmel,CA 93923, phone(408) 647-4456. 


X3 seeks participants for 

Accredited Standards Committee X3, 
Information Processing Systems, has 
approved a project to develop an 
addendum for tiled raster graphics for 
ISO 8613, Office Document Architec¬ 
ture/Office Document Interchange For¬ 
mat (ODA/ODIF). When approved 
internationally, the addendum will be 
adopted as an American National 
Standard. 


ISO 8613/7 

The addendum will extend the capa¬ 
bilities of raster graphics to meet user 
requirements in engineering drawing 
and technical publishing. The new ele¬ 
ments will extend the current raster 
graphics content architecture to 
describe a tiled raster graphics content 
architecture. 

X3V1 plans to complete the adden¬ 
dum this year. It thus requests all 


interested parties to immediately con¬ 
tact the X3V1 chair, L. Millard Collins, 
IBM, 03-03-50, 5 W. Kirkwood Blvd., 
Roanoke, TX 76299-0001, phone (817) 
962-4392. 

Task Group X3V1.5 will perform the 
actual development work. X3V1.5 will 
also maintain contact with the joint 
ISO/CCITT committee on picture 
coding. 
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PRODUCT REVIEWS 


Editor: Richard Eckhouse, MOCO, Inc., PO Box A, 91 Surfside Rd., Scituate, MA 02055; Compmail+, r.eckhouse 


The bridge machine 

Richard Eckhouse, Product Reviews editor 


When most of us think of a 386, we 
have an image of the top-of-the-line mi¬ 
croprocessor for the IBM PC series of 
personal computers. But Sun has used 
this powerful microprocessor in an in¬ 
triguing way — to bridge the gulf be¬ 
tween the MS-DOS and Unix worlds. 

The Sun 386i is billed as a “bridge 
machine” for very good reasons. It sup¬ 
ports both operating systems and makes 
it easy to painlessly move from the fa¬ 
miliar DOS environment to the more 
powerful Unix world. Sun has achieved 
some pretty impressive results sure to 
pleasantly surprise and please many us¬ 
ers. 

First impressions 

For my review, Sun provided a Sun 
386i/250 with 8 Mbytes of dynamic 
RAM on its own 32-bit system bus card. 
It came with a 32-Kbyte memory cache 
and an 80387 coprocessor, both standard. 
Also standard were Sun’s version of the 
IBM 101-key keyboard, an optical 
mouse, and a 3.5-inch 1.44-Mbyte floppy 
drive. The system also came with a 15- 
inch color monitor (made by Sony) and a 
327-Mbyte full-height hard disk. The 
machine has a built-in Ethernet adapter, 
plus an SCSI connector for adding exter¬ 
nal drives, which fit in a box that at¬ 
taches to the top of the system unit. 

The system unit is about the size of a 
standard AT box. It took me only a few 
minutes to open the shipping boxes and 
install the various cables that connect the 
system unit to the monitor and keyboard 
plus mouse. After I powered up the sys¬ 
tem, it went through boot-up and I 
logged in to SunOS. By preconfiguring 
the system and loading the hard disk, 

Sun had made it nearly effortless for any 
user to use the system without hassles or 
confusion. In fact, the documentation in¬ 
cluded a well-illustrated setup flyer for 
those of us who read the manuals when 
all else fails. 

Speaking of manuals. Sun has put to¬ 
gether an impressive four-manual set that 


includes System Setup and Maintenance , 
User's Guide, Advanced Skills, and 
SNAP Administration (for the System 
and Network Administration Program). 
Helpful and tutorial, these manuals are 
complemented by the on-line, context- 
sensitive, hypertext help system belong¬ 
ing to the Suntools set that comes with 
each machine. However, the new Sun/ 
Unix user might need the much larger set 
of manuals available but not included 
with the 386i. 

Since SunOS is a windowing system, 
the Suntools provide a point-and-click 
user interface, supported by icons, called 
the Desktop. While mouse haters might 
not care for this, I found it a familiar and 
comfortable metaphor that provides ex¬ 
cellent flexibility. I also discovered that 
putting the mouse at the left of the key¬ 
board (I am right-handed) makes it less 
distracting when I have to use the mouse 
instead of the keyboard. Sun offers this 
flexibility by providing symmetrical 
mouse connectors on either side of the 
keyboard. Now, if only they would offer 
a trackball, I would be even happier. 

The Suntools include the Sun Organ¬ 
izer for working with files, the MailTool 
for e-mail, a text editor, a clock, and the 
Sun Shell/Command windows. You can 


configure your system so that the tools 
appear as open windows or icons when¬ 
ever you log in. The overlapping win¬ 
dows include the usual basics for nam¬ 
ing, scrolling, and framing. A window 
becomes active when the mouse cursor is 
contained within it. Pull-down and pull- 
right menus offer a multitude of selec¬ 
tions supplemented by the left keypad, 
which provides an assortment of func¬ 
tions to make using the Desktop easier. 
Examples are the Help, Undo, Front, and 
Properties keys. 

I have a minor complaint with all of 
this: the assignment of functions to the 
mouse keys. The left button selects a 
screen object. The middle button moves 
or extends screen objects. The right but¬ 
ton brings up a menu and allows you to 
select a menu option. To this day I still 
confuse the functions of the right and left 
mouse buttons. That might come from 
my DOS experiences, but I wish I could 
remap these buttons to my liking. 

Software and hardware 
options 

The Sun386i is available in two mod¬ 
els. The first, called the Sun386i/150, 
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runs at 20 MHz and is rated at more than 
3 MIPS. The base machine comes with 4 
Mbytes. The second, called the Sun386i/ 
250, runs at 25 MHz and is rated at more 
than 5 MIPS. The base memory is 8 
Mbytes, and a 32-Kbyte cache is in¬ 
cluded. An 80387 coprocessor comes 
with both systems. Either model can be 
expanded to the maximum memory of 16 
Mbytes. 

These machines are housed in an un¬ 
cluttered floor-standing cabinet. They 
use a single-board design and a 
backplane that includes three AT-style 
slots and one XT-style slot. The AT/XT 
bus runs at 5 MHz on the model 150 and 
6.25 MHz on the model 250. While the 
AT/XT bus provides compatibility for 
PC boards, you do have to be careful not 
to use boards that generate non-maskable 
interrupts or require a specific timing to 
operate. You don’t need EMS boards be¬ 
cause the SunOS provides a full 2 
Mbytes of EMS memory for each DOS 
window. 

In addition to the SCSI controller, a 
serial and parallel port also come stan¬ 
dard. A custom ASIC chip is used for the 
built-in Ethernet interface. SIMM mem¬ 
ory modules on their own board plug into 
one of the three 32-bit bus slots. A color 
or monochrome frame buffer uses an¬ 
other 32-bit slot. The 386i’s built-in 
memory management is used to provide 
a 4-Gbyte virtual memory environment. 

Disk drives come in two sizes: 91 
Mbytes and 327 Mbytes. You can op¬ 
tionally expand your system to 981 
Mbytes of disk storage. Screen resolution 
is 1,152 x 900 on larger screens and 
1,024 x 768 on the smaller 14-inch color 
monitor. Color and resolution are excel¬ 
lent. In the B/W mode, you have a white 
background with black letters. In color 
mode, you have full control of all win¬ 
dow and icon colors, choosing from 256 
colors out of a palette of 16.7 million. 

Prices range from $7,990 for a diskless 
workstation to $13,990 for the top-of- 
the-line model. 


Power of the system 

As a workstation, the 386i provides 
full source-level compatibility across 
Sun’s different hardware platforms. The 
operating environment, SunOS (currently 
version 4.01), is a merged version of the 
Unix System V.3 and Berkeley 4.2/4.3 
operating systems. Included are the Sun 
View windowing system, automated sys¬ 
tem installation and administration facili¬ 
ties, hypertext help, and the various tools 
mentioned earlier. All of this software is 
preinstalled on the hard disk, along with 
NFS and integrated Ethernet hardware. 

However, “cluster” software is not 


present on the preconfigured machine. 
This software includes the manual pages, 
spell check, accounting, etc. A system 
command. Load, makes the process of 
adding the cluster software a snap, but 
since only a 1.44-Mbyte 3.5-inch drive 
comes standard, the operation is time 
consuming. Fortunately, a 60-Mbyte 
backup tape drive in the expansion unit 
makes this, as well as a complete system 
backup, much easier. Also, both SunOS 
and DOS can read and write to the 3.5- 
inch drive in both high- (1.44-Mbyte) and 
low- (720-Kbyte) density modes. 

While not a true IBM PC because ev¬ 
erything is emulated and there is no ROM 
BIOS support, the 386i performs admira¬ 
bly. The VP/ix software from Phoenix 
Technology provides a reasonable MS- 
DOS environment with multiple hard and 
floppy drives available. Like Windows/ 
386 (and others), the DOS environment 
operates in the 386’s virtual-86 mode. All 
but one of the “hard” drives are actually 
Unix files accessible from either DOS or 
Unix. The exception, the C drive, emu¬ 
lates the characteristics of a true DOS 
device for copy-protected software that 
makes sector level requests. 

You can have multiple DOS windows 
running at the same time, but only one 
can access the C drive. Isolation between 
windows is excellent, and you can reboot 
a DOS window. Also, with three display 
adapter types to choose from (Hercules, 
CGA, and monochrome, with VGA in the 
future), you can have the same or differ¬ 
ent applications running in different 
graphics modes. But you must remember 
to perform the proper Mode command 
before switching modes or you won’t get 
the desired effect. 

Normally, the mouse belongs to 
SunOS. However, if you install the 
mouse software, you can call up a menu 
to assign the mouse to the DOS partition. 
Because of the emulation of the graphics 
modes, screen updates and hence mouse 
responsiveness are sluggish. I tried run¬ 
ning EasyCAD as a compatability test 
and found everything worked just like it 
does on my PC, albeit somewhat slower. 

Those who choose to think of this as a 
DOS machine will face some disappoint¬ 
ments. First, a few seemingly vanilla ap¬ 
plications (a word processor and Micro¬ 
soft’s mouse-based Game of Life) run 
only partially or not at all. In fact, the 
game locked up the window, while the 
spell checker in the word processor 
caused the DOS window to simply close 
down. In the latter case, the system error 
message said I had an unimplemented 
286 instruction — which was simply not 
so. Nonetheless, while Sun does not 
promise 100-percent compatibility, most 
other applications that I tried ran without 
a hitch. 



Second, you will encounter the already 
mentioned slow keyboard and mouse re¬ 
sponsiveness in a DOS window. This is 
not true for Unix, where responsiveness 
is excellent. And when it comes to raw 
computing power, the 25-MHz 386 per¬ 
forms admirably, offering performance 
on a par with other DOS- or Unix-based 
386-machines. So the CPU cycles are 
there, and it seems likely that Sun will 
fix the display problems in later versions 
of the software and hardware. 

Bridging DOS and Unix 

The key feature of the 386i is its 
nearly seamless integration of DOS and 
Unix. You can run native-mode DOS and 
Unix programs from either environment. 
Using pipes, you can link utilities from 
each. Often, the only distinction you 
need to access files in DOS or Unix is to 
switch from the backslash to the slash in 
naming files. If more is required, the 
utilities dos2unix and unix2dos convert 
file formats from one form to the other. 

As is typical in a windowed system, 
you can copy and paste between win¬ 
dows and move files back and forth be¬ 
tween the environments. This feature 
combined with the SunOS multiuser, 
multitasking operating system allows 
you to work in multiple DOS and Unix 
windows, rapidly switching between the 
two. For Unix users, this provides access 
to popular PC applications such as 
spreadsheets, word processors, and data¬ 
base systems. For DOS users, this means 
access to the applications development 
environment that Unix provides. 

Networking 

One of the features touted about work¬ 
stations is the ability to use them without 
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a disk. I tested this in the heterogeneous 
network at the University of Massachu¬ 
setts at Boston, using VAX machines, 
Sun-3 and -4 workstations, and personal 
computers. The results were impressive 
and natural with the 386i as a Unix 
workstation. From the ease of connecting 
the 386i into our network to the transpar¬ 
ent access to all my files and the System 
utilities, the system proved flexible and 
responsive. 

On the other hand, in the DOS world it 
was obvious that I was on a network. It 
appeared that no disk caching or buffer¬ 
ing took place, and many applications 
started slowly and bogged down on disk¬ 
intensive operations. While this wasn’t 
much different than I’ve seen on many 
networked DOS systems, it wasn’t as 


Review notes 

A relational database manage¬ 
ment tool. RDM from Interactive 
Technology, 460 Park Plaza West, 
10700 SW Beaverton-Hillsdale Hwy., 
Beaverton, OR 97005, phone (503) 
644-0111, offers the professional de¬ 
veloper a relational database and a 
full set of application development 
tools to build multisystem, on-lihe 
applications. 

RDM is organized into programs 
and tables, which are special data 
files. The programs create files, input 
or edit data through screen forms, 
print reports, run processes, and per¬ 
form a variety of Other data manage¬ 
ment utility functions. You can tailor 
the RDM programs through the en¬ 
tries in the tables. The forms program 
creates data input screens and accepts 
data from them. The user tables pro¬ 
vide the specific details of a particular 
form: the file into which the data is to 
be placed, the position of the input 
blanks on the screen, and the head¬ 
ings to be displayed. 

The RDM development system it¬ 
self uses forms, menus, and com¬ 
mands created using tables. RDM 
runs not only on MS-DOS machines, 
but also on the PDP-11, VAX, and 
under Xenix on 286 ahd 386 ma¬ 
chines. 

Applications developed for one 
computer will run almost without 
modification on each of the others. I 
found it useful to run an RDM appli¬ 
cation on a DOS machine connected 
via DECnet with a VAX and to main¬ 
tain the database on the VAX. RDM’s 
definition style allows you to create 
your own automated data systems. 


impressive as running Unix over the 
same network. 

Summing it up 

As you can tell, I was impressed by 
the 386i. I’ve used both models with 
color and B/W monitors. Although I 
started with a stand-alone system, I 
moved to a network environment. Along 
the way I made the transition from being 
primarily a DOS user to a combination 
DOS/Unix user. Frankly, I owe a lot to 
Sun for making this bridge possible with 
their fine machine and the excellent 
manuals that anticipated many of my 
questions. 

Equally important, the 386i has inte¬ 
grated my divergent needs for both a 


Unix and a DOS machine. For example, I 
can upload DOS applications to the 386i, 
then, using DOS software, produce net¬ 
work files that my students can access. I 
can test and run DOS applications as well 
as Unix applications with ease. In short, I 
now have the best of both worlds. 

While I have mentioned a few short¬ 
comings or changes I’d like to see, I find 
the 386i well worth its price. Thus, I 
have recommended it highly to others 
and will continue to use it as my network 
host. I also heartily recommend it to the 
reader. 

Contact Sun Microsystems at 2550 
Garcia Ave., Mountain View, CA 94043, 
phone (415) 960-1300. 
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RDM offers a way to create appli¬ 
cations by specifying erid results, 
since RDM applications are built by 
filling in tables rather than by proce¬ 
dural language. The PC version of 
RDM costs $895; the VAX version, 
up to $24,000. — M. Dediu 

Ethernet laptop protocol ana¬ 
lyzer. Networking is a necessity for 
many computer users, but how do you 
check that the network is OK? For an 
Ethernet network you can use the 
Sniffer Model PA-302 Version 2.0, 
which is a self-contained laptop 
protocol analyzer. This analyzer is 
usually passive except for two modes: 
Traffic Generator or Cable Tester. It 
captures images of all or some se¬ 
lected frames (packets) in a working 
buffer, ready for immediate analysis 
and display. 

The frame selection, using the com¬ 
mand Capture, is based on lower- 
level protocol content, node ad¬ 
dresses, pattern matching, and/or 
frame error conditions. When you use 
Capture, network traffic information 
appears on the unit’s video screen, 
with an audible click marking the 
storage of each frame. You have op¬ 
tional formats for displayed data. You 
can analyze the number of frames ac¬ 
cepted, kilobytes accepted, defective 
frames counted, and buffer utiliza¬ 
tion. 

Filters based on address level, node 
addresses, protocol content at all lev¬ 
els, defective frames, and pattern 
matching can be invoked through the 
menus for selecting all or a portion of 
the captured frames for display. You 


can analyze tabular-organized infor¬ 
mation about the protocol content of 
the selected frames (in plain English), 
plus address, timing, frame size, cu¬ 
mulative byte count, network utiliza¬ 
tion data, and summary views. More 
advanced users can write C programs 
for their own higher-level protocol 
interpreters and link them into the 
Sniffer’s software to extend the full 
protocol interpretation capability. 

The TeleSniffer feature permits re¬ 
mote control of all Sniffer functions 
from a telephone-line-connected PC. 
A universal power supply adapts the 
unit to international power sources. 

The Sniffer costs $15,750 and is 
available from Network General, 

1945A Charleston Rd., Mountain 
View, CA 94043, phone (415) 965- 
1800. — M. Dediu 

Ruggedized systems. Rough envi¬ 
ronments with heavy vibration, 
shocks, and jolts are often disastrous 
for hard disks. Now Mini Computer 
Technology, 696 E. Trimble Rd., San 
Jose, CA 95131, phone (408) 435- 
1616, offers a solution in the form of 
its Ruggedized Disk System (desig¬ 
nated the RHD and RUDS). These 
certified systems come in both 3.5- 
and 5.25-inch drives with capacities 
from 20 to 760 Mbytes. 

Drives can be installed in daisy- 
chain packaging of single, dual, or 
quad chassis rack mounts (in this last 
configuration, you can have up to 3 
Gbytes of storage). These portable, 
rugged drives stand up to 5.6 RMS 
20-1,000 Hz operating vibrations and 
15 G’s (customized to 30 G’s) of op- 
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Programmer’s editors 

Daniel McAuliffe, Celtic Software 


Every computer programmer appreci¬ 
ates the importance of a good program 
text editor. Aside from the language 
compiler itself, the programmer’s editor 
is the most important tool available to a 
programmer. Upgrading your favorite 
program editor offers the potential for a 
substantial increase in productivity. A 
fast, powerful, and flexible text editor 
can save many hours of expensive pro¬ 
grammer time. This review takes a look 
at five of the most prominent program¬ 
mer’s editors available and gives you 
some idea of the features they offer. 


erating shock. They do not depend 
upon rack isolation because they are 
internally shock isolated. 

Operating temperature ranges from 
0 to 50 degrees C. You can readily 
remove the units for storage and data 
security. In addition to withstanding 
shock, vibrations, and humidity, these 
units also meet 50,000-foot altitude 
requirements. 

The standard MCT RHD removable 
module is 9.75 inches high, 3.5 inches 
wide, and 11.8 inches deep and weighs 
14 pounds. It requires external fan 
cooling and power. The power re¬ 
quired for the Mount/RHD assembly is 
115V, 48-400 Hz, single phase. 

The signal interface is the industry 
standard SCSI/CCS. The data rate is 
1.8 Mbytes/s. The RHD has sensors 
and associated circuitry located inter¬ 
nally. These sensors provide self pro¬ 
tection. If the internal atmospheric 
pressure (altitude) exceeds the given 
specifications, the disk drive motor 
shuts down. The drive electronics re¬ 
main powered up for communication 
with the rest of the system. If the inter¬ 
nal temperature exceeds its specified 
limit, the same process occurs. When 
the RHD is used in conjunction with 
any of the family of MCP controllers, 
the status of each sensor is readable by 
the system whenever power is applied 
to the mount. 

The RHD currently stores 40 
Mbytes of data, with 80 Mbytes avail¬ 
able in the near future. The RUDS is a 
300-Mbyte removable disk. 

Prices for these disk drives range 
between $5,000 and $15,000. — M. 


Vedit Plus 

Vedit Plus from CompuView is adver¬ 
tised as the fastest programmer’s editor 
available in the marketplace, and that 
may very well be true. It is also ex¬ 
tremely adaptable, small in size, and re¬ 
quires only slightly more than 42 Kbytes 
of memory. 

You perform the initial installation of 
Vedit Plus with a batch file supplied by 
CompuView. Two preconfigured ver¬ 
sions of the program are available for the 
IBM PC system. One is memory mapped 
and uses direct screen access for fast up¬ 
date of the display. The other operates 
through the IBM ROM BIOS. Although 
slower to update the display screen, it 
behaves much better in environments 
such as Microsoft Windows. 

You must answer a minimal number of 
questions during the installation process. 
You can choose to install Vedit Plus on a 
hard disk or a floppy disk, specify the 
color scheme if you have a color moni¬ 
tor, and select which language compilers 
you wish to run from within Vedit Plus. 
Selections are available for Microsoft C 
Version 4.0, MASM, Aztec C, and a 
number of others. You also choose the 
keyboard layout you would like to use, 
whether novice, expert, Wordstar, or 
WordPerfect. If you install Vedit Plus on 
a hard disk, all files are initially placed 
in the subdirectory \vedit. 

Once you have completed the initial 
installation, you can create a new version 
of Vedit Plus at any time by running the 
program Install. You can modify numer¬ 
ous parameters defining program per¬ 
formance, the most important being the 
layout of the keyboard and the building 
of keystroke macros. When building a 
new keyboard layout, you are prompted 
for each of the new key definitions. You 
can create any number of program con¬ 
figurations and store them on disk. 

Vedit Plus operates in two separate 
modes: visual and command. Single¬ 
character keyboard commands allow you 
to quickly switch between the two 
modes. In visual mode, you can edit up 
to 37 separate files simultaneously, each 
of unlimited size. Each edit session can 
take place in a separate window. The 
windows can be vertical or horizontal, 
and you can specify the size, placement, 
and color of any of the windows. You 
can freely switch between 25- and 43- 
line display modes if you have an EGA 
adaptor. You can also create a special 
window for command mode operation. 


Keystroke macros are available for de¬ 
fining “hot keys.” You can define any 
number of keystroke macros either at in¬ 
stallation or during normal operation. 
Visual mode keystroke macros can com¬ 
bine visual mode functions and com¬ 
mand mode commands. 

Vedit Plus supplies a set of 36 unique 
text registers. These text registers are ar¬ 
eas of memory where Vedit Plus stores 
text that is independent of the main text 
you are editing. Text can move in and 
out of the registers for cut-and-paste op¬ 
erations, or you can store command mac¬ 
ros in the text registers. Command mac¬ 
ros are separate and in addition to key¬ 
stroke macros. They are groups of com¬ 
mands stored in text registers for imme¬ 
diate or later use. You can save them to a 
disk file and later reload them into the 
text registers. You can create a new com¬ 
mand macro or modify an existing macro 
by editing the corresponding text register 
in visual mode. The macro can then be 
executed with a single keystroke. These 
are called “off the cuff’ macros. 

A number of predefined macros come 
with Vedit Plus. These include a print 
macro for sending formatted data to a 
line printer, a file comparison macro for 
finding the differences between two text 
files, and a file search macro similar to 
the Unix Grep function. 

The real power and flexibility of Vedit 
Plus lies in the command mode. Com¬ 
mands are available for performing virtu¬ 
ally any function a programmer might 
envision, from resetting the horizontal 
tab columns to enabling auto indentation, 
manipulating the visual mode windows, 
or compiling the source code from within 
the editor. Sequences of commands can 
be strung together to form macros, 
loaded into any one of the 36 text regis¬ 
ters, stored on disk for future use, and 
later recalled and executed. In fact, you 
can write entire programs using the com¬ 
mand language. The Vedit Plus tutorial 
program was written using only the pro¬ 
gramming language. 

In addition to the large collection of 
basic commands in the language, you get 
conditional testing, conditional and un¬ 
conditional jumps, looping operations, 
and interactive input and output opera¬ 
tions. A powerful pattern-matching fea¬ 
ture for searching a text file is also avail¬ 
able. You can not only search for par¬ 
ticular characters, but also for types of 
characters such as “any digit,” characters 
that meet special conditions such as “oc¬ 
curring at the beginning of a line,” or any 
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five-letter word beginning with the char¬ 
acter “t” and ending with the character 
“n.” 

The command mode even offers an on¬ 
line calculator feature. 

Extensive on-line help facilities are 
available with Vedit Plus. The help fea¬ 
tures are implemented using ASCII text 
files that you can modify to suit your 
needs or replace entirely. 

The only complaint I have with Vedit 
Plus concerns the Undo function. Vedit 
Plus provides a limited version of this 
function. You can undo the changes you 
have made to a line of text only if you 
execute the Undo before moving the cur¬ 
sor off the line. This feature could defi¬ 
nitely stand improvement. 

The documentation for Vedit Plus con¬ 
sists of a single volume in a three-ring 
binder. It includes a tutorial section, a 
user’s guide, a programming guide, an 
installation guide, and a reference guide. 
The programming guide contains a de¬ 
tailed description of each of the Vedit 
Plus commands with examples. The 
manual is one of the best I have seen. 

If you want to upgrade your current 
programmer’s editor, I strongly suggest 
you at least send for a free copy of the 
Vedit Plus demonstration and tutorial 
disk. I am sure you will be impressed 
with the speed, power, and flexibility of 
the program. 

Vedit Plus supports the IBM PC, XT, 
AT, and PS/2. It also supports MultiL- 
ink, PC-MOS/386, Concurrent DOS, and 
most networks. It is available for MS- 
DOS, FlexOS, CP/M-86, and CP/M. 

Vedit Plus, Version 2.03f, is available 
from CompuView Products, 1955 
Pauline Blvd., Ann Arbor, MI 48103, 
phone (313) 996-1299. The retail price is 
$185. 
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BRIEF 

BRIEF, which stands for Basic Recon- 
figurable Interactive Editing Facility, of¬ 
fers power and performance to satisfy the 
needs of the most demanding profes¬ 
sional computer programmer, as well as 
ease of use for those individuals looking 
for a basic editor with limited word proc¬ 
essing features. 

You initially install and configure 
BRIEF with a setup program supplied on 
one of the two 5.25-inch disks containing 
the system. During the installation, the 
setup program modifies the Autoexec.bat 
and Config.sys files, making backup cop¬ 
ies of each of these files before any 
changes are incorporated. During instal¬ 
lation, excellent on-line help facilities 
are available at every point where the 


program prompts you for information. 
Once you have installed the initial ver¬ 
sion of BRIEF, you can reconfigure the 
program at any time using the same setup 
program. The setup program is entirely 
menu-driven, with entries for modifying 
characteristics such as where backup 
files are stored, the shape of the cursor, 
the number of commands you can undo, 
the maximum line length, and the opera¬ 
tion of the Tab key. 

You invoke BRIEF by typing “b file¬ 
name.” You can give more than one en¬ 
try for “filename,” as in “b filel.c file2.c 
file3.c.” In fact, the parameter “file¬ 
name” can contain a wildcard, such as 
“*.c.” In this case, BRIEF will load each 
of the files having a .c extension into its 
own edit buffer. 

BRIEF maintains a list of all the files 
currently in edit buffers. You can display 
the buffer list, select an entry from the 
list, delete a file from the list, or write a 
file on the list to disk. 

Each edit buffer can be associated 
with a screen window. You create win¬ 
dows by selecting the Create Window 
function and using the cursor movement 
keys to specify the direction in which the 
new window is to lie. The screen then 
splits to make room for the new window. 
You also use the cursor keys to move be¬ 
tween windows, delete a window, and 
resize a window. The same file can ap¬ 
pear in more than one window. When¬ 
ever you change the file in one of the 
windows, that change appears in each of 
the other windows containing the file. 

You can easily move data between win¬ 
dows by using block marks and a scrap 
buffer for cut-and-paste operations. 

BRIEF has a powerful facility for 
searching text using regular expressions. 
You can specify a set or range of charac¬ 
ters to be used in a pattern or to be ex¬ 
cluded from the pattern. For example, the 
regular expression [AEIOU] matches an 
uppercase vowel while the expression 
[-AEIOU] would match any character 
except an uppercase vowel. Characters 
can also be grouped together using curly 
braces. In this instance, the expression 
{him} I {her) would match either the pat¬ 
tern “him” or the pattern “her.” You can 
also turn off regular expressions if you 
need to search for any of the regular ex¬ 
pression characters, such as question 
marks. 

One of the most useful features of 
BRIEF is the Undo function. Virtually 
anything that you can do with the editor 
you can also undo. You can undo as 
many as 300 previous operations in the 
reverse order in which you entered them. 
This number applies to each of the edit 
buffers you are using. You can even 
undo the effect of your macros. 

BRIEF supports program compilation 


from within the editor. Many of the 
popular C compilers, Fortran compilers, 
Pascal compilers, and assemblers are 
supported, including the BRIEF macro 
compiler. If it encounters errors during 
compilation, BRIEF positions the cursor 
at the beginning of the first line contain¬ 
ing an error. A single keystroke can ei¬ 
ther move the cursor to the next line con¬ 
taining an error or list the set of all er- 

The BRIEF macro language is the 
strongest feature of the program package. 
You can add commands to the editor, 
modify existing commands, create a 
unique environment for any program¬ 
ming language, and tailor the look and 
feel of BRIEF to satisfy your personal 
tastes. The syntax and structure of the 
language resembles the MLisp language 
found in EMACS editors. 

You build a macro as an ASCII file 
from language primitives using the text 
editor. You then compile the file using 
the BRIEF macro compiler. If the com¬ 
piler finds an error, the cursor is posi¬ 
tioned at the beginning of the line con¬ 
taining the error. Once the macro is com¬ 
piled successfully, it can be executed like 
any other BRIEF command. You can 
save both the source language macro file 
and the executable file for future use. 
Each macro source file can contain a col¬ 
lection of related macros. You can then 
load the entire macro file and execute the 
individual macros. 

If you are familiar with the C pro¬ 
gramming language, you will feel right 
at home with the BRIEF macro language. 
The language uses the compiler directive 
“#include” as well as the familiar primi¬ 
tives Break, Continue, If, While, and 
Switch. Integer and string variables are 
allowed, either local or global. Arithme¬ 
tic and conditional primitives are avail¬ 
able, together with the string functions 
Atoi, Lower, Strlen, and Sprintf. 

BRIEF has a number of different types 
of macros. You can assign command 
macros to a key or key sequence. The 
file “startup.cm” contains a startup 
macro, which is loaded and executed 
each time you invoke BRIEF. In addi¬ 
tion, each time any macro file is loaded, 
a macro called “_init” is run if found in 
the file. 

Another type of BRIEF macro is the 
file extension macro. When you invoke 
BRIEF to edit a file, it automatically 
checks for a file of the same name as the 
file’s extension. For example, if you are 
editing the file “file.c,” BRIEF looks for 
a macro named “.c.” Macros of this type 
for the C language and the BRIEF macro 
language are built into BRIEF. 

BRIEF also provides registered mac¬ 
ros, which are macros called any time 
certain events occur during an editing 
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session. Some of the events predefined in 
BRIEF are typing a character, creating a 
buffer and reading a file into it, changing 
from one buffer to another, and typing an 
invalid character while responding to a 
prompt. You register macros for any of 
these events with the Register_macro 
function and unregister them with the 
Unregister_macro function. 

The documentation package consists 
of a user’s guide, a macro language 
guide, and a quick reference guide. The 
user’s guide contains an extensive tuto¬ 
rial to help you get started with the pro¬ 
gram. A command reference section lists 
each of the BRIEF commands along with 
its default key assignment and an expla¬ 
nation of the command function. The 
macro language guide also contains an 
excellent tutorial on the language to¬ 
gether with a detailed example of the 
creation of a complex macro to save and 
restore the state of a BRIEF editing ses- 

BRIEF contains many excellent fea¬ 
tures not mentioned in this review. It is 
an extremely powerful and flexible edi¬ 
tor that will satisfy the needs of the most 
demanding programmer. I highly recom¬ 
mend it. 

BRIEF, Version 2.1, is available from 
Solution Systems, 541 Main St., Suite 
410D, South Weymouth, MA 02190, 
phone (617) 337-6963. It costs $195. 
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Epsilon 

Those readers familiar with the 
EMACS text editor found on many larger 
computers will feel right at home with 
the Epsilon text editor. If you are not ac¬ 
customed to the EMACS editor, you can 
easily customize Epsilon to emulate 
nearly any editor of your choice. 

The Epsilon software package comes 
on two 5.25-inch disks. Disk 1 contains 
the editor, an Epsilon Extension Lan¬ 
guage compiler, and support files. Disk 2 
contains all of the source code for the 
Epsilon commands. 

A brief tutorial is included as part of 
the system, invoked with the command 
line switch “-teach.” Very elementary, it 
covers only enough of the basic informa¬ 
tion to get you started using Epsilon. 

Epsilon provides more than 145 prede¬ 
fined commands. You can assign a com¬ 
mand to each of 340 distinct keys. You 
can use each of the 340 keys as a prefix 
command allowing access to an addi¬ 
tional 340 keys. Clearly, enough differ¬ 
ent keystrokes are available to define as 
many commands as you desire. 

The initial configuration emulates the 
EMACS editor in the manner in which 


commands are assigned to individual 
keystrokes. You execute commands by 
striking the appropriate key or by execut¬ 
ing the command Named-command, ini¬ 
tially assigned to the Alt-X key. The pro¬ 
gram then prompts you for the name of 
the command you want to execute. You 
can change any key assignment with the 
Bind-to-key command. The command 
asks for the command name and the key¬ 
stroke assignment. 

You can alter many of the features of 
Epsilon besides the key assignments, in¬ 
cluding tab key spacing, screen colors, 
and case sensitivity. You can then save 
the entire configuration on disk with the 
Write-state command. You can save as 
many system states as you need with dif- 


Epsilon has a nice Undo 
command specific to each 
edit buffer. 


ferent file names and reload them when 
you need them. 

A very nice help facility is built into 
Epsilon, invoked with the F10 function 
key. You can then choose one of three 
different methods of displaying informa¬ 
tion on Epsilon topics. The first displays 
information on a particular key when you 
enter that key, the second describes a 
command when you enter the command 
name, and the third, referred to as apro¬ 
pos, lists all commands associated with a 
particular keyword. The help system will 
also generate a command listing for easy 
reference. 

Epsilon includes a feature called 
“completion.” When you enter a com¬ 
mand by name. Epsilon determines 
which command you are referring to as 
soon as you have typed enough letters 
for it to distinguish the command. It then 
completes the command. For example, if 
you type the first letter of a command 
followed by a space, Epsilon completes 
as much of the command as possible. 

You then type more command letters fol¬ 
lowed by another space and Epsilon fills 
in more of the command. You can con¬ 
tinue in this way until all of the com¬ 
mand is filled in. At any time you can 
enter the “?” character and Epsilon will 
provide a list of all of the commands that 
match the letters already entered. 

Epsilon has a nice Undo command 
specific to each edit buffer. It will re¬ 
member between 500 and 1,500 previous 
commands, depending on the complexity 
of the command — enough for the most 
demanding user. It also includes a unique 
Redo command. If you press the Undo 


command and then decide that you want 
to retrieve the commands. Redo will 
automatically recall those commands for 
you. 

Epsilon has a limited keyboard macro 
facility. The key sequence C-X-( begins 
a macro definition and the sequence C- 
X-) ends the macro definition. This cre¬ 
ates a macro called the “last-kbd-macro.” 
It can be executed at any time with the 
C-X-E command sequence. You can then 
rename the macro with the Name-kbd- 
macro command. The macro is then 
available as an extended command and 
can be assigned to any key. 

Epsilon implements text movement 
with the aid of “kill-buffers.” You can 
have as many as 32 of these buffers. Re¬ 
gions are initially marked, the data saved 
to a kill-buffer, and then yanked back 
from the buffer and inserted at any point. 
This cut-and-paste method is powerful 
and flexible. The only problem I found 
was that the region is not clearly high¬ 
lighted when marked. 

The strongest feature that Epsilon has 
to offer is the Epsilon Extension Lan¬ 
guage (EEL). All of the Epsilon com¬ 
mands are written in EEL, and the source 
code for the commands is supplied along 
with the editor. The syntax of EEL is 
remarkably similar to the C program¬ 
ming language. Learning to use EEL is 
like learning to use a new library of C 
functions. Data types such as integer, ar¬ 
rays, structures, and pointers are avail¬ 
able in the language. You can also define 
your own data types and allocate data ob¬ 
jects dynamically. The language imple¬ 
ments a full set of control flow features, 
including If, While, Do, Switch, and 
Goto. A nonlocal Goto facility uses 
Setjmp and Longjmp. 

EEL offers a rich set of primitives and 
subroutines. The primitives cover opera¬ 
tions dealing with the manipulation of 
buffer contents, such as inserting and de¬ 
leting characters and searching and sort¬ 
ing the contents of a buffer. You will 
find all of the standard C language func¬ 
tions in EEL, such as Strlen, Strcpy, 
Strncmp, and Sprintf. Primitives avail¬ 
able for controlling Epsilon windows let 
you split windows, kill windows, and 
size windows. EEL primitives such as 
File_read, File_write, and Rename_file 
permit extensive file manipulation. Even 
software interrupts can be controlled 
from within EEL. Clearly, commands 
created with EEL can rival the most 
powerful C language programs. 

The documentation set for Epsilon 
consists of a single 7 x 9-inch spiral- 
bound manual. It is very complete, con¬ 
taining chapters on an introductory tuto¬ 
rial, the general concepts behind Epsilon, 
a discussion of the commands by topic, 
an alphabetical listing of each Epsilon 
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command, and extensive sections on the 
Epsilon Extension Language and the sys¬ 
tem primitives and subroutines. The only 
fault I could find with the manual is the 
lack of examples in many of the sections. 
With the manual comes a quick reference 
guide. 

Version 4.0 of Epsilon is available for 
$195 from Lugaru Software, 5843 Forbes 
Ave., Pittsburgh, PA 15217, phone (412) 
421-5911. Versions are available for the 
IBM PC, AT, PS/2, or compatibles with 
256 Kbytes or more, under DOS, OS/2, 
Microport Unix, or SCO Xenix. 
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Norton Editor 

If you have little need for the sophisti¬ 
cated macro language facilities found in 
Vedit Plus, BRIEF, or Epsilon and cost is 
a prime consideration in your selection of 
a programmer’s editor, then take a look 
at the Norton Editor. It is extremely easy 
to learn and use and requires only 30 
Kbytes of disk space. 

If you have a hard disk, you install the 
editor simply by copying the contents of 
the disk to the directory of your choice 
and modifying the DOS search path. If 
you do not have a hard disk, this small 
program can operate directly from a 
floppy disk while editing a sizable pro¬ 
gram file. 

You can customize a number of pro¬ 
gram features from within the editor, 
such as tab width setting, cursor type, 
screen color, and automatic indentation. 
You can configure any number of ver¬ 
sions of the program and preserve them 
on disk. 

The Norton Editor can act on two sepa¬ 
rate files at once. Each file appears in a 
separate window on the display screen. 
The screen is always split horizontally 
when editing the two files. 

Primary access to the editor features is 
through the function keys. Each function 
key has a specific, unchangeable mean¬ 
ing. 

The FI function key displays a set of 
help screens. These consist of one-line 
definitions of each of the program key¬ 
strokes. 

The F2 function key displays the cur¬ 
rent status of the edit session. This in¬ 
cludes the current tab width setting, the 
number of characters in the edit buffer, 
and other miscellaneous information per¬ 
taining to the status of the printer and 
unused space in the edit buffer. 

The F3 function key followed by a 
single letter invokes one of a number of 
commands relating to file operations. For 
instance, F3-N prompts you for the name 
of a new file to edit, while F3-S will save 


the current file to disk and continue the 
edit session. 

The F4 function key controls access to 
the editor block commands. The block 
commands operate on the text contained 
between two block markers, set with the 
F4-S key sequence. Operations on the 
block include deleting the block, copying 
the block to the current cursor location, 
and copying a marked block from one 
window screen to the other window 
screen. 

The F5 function key enables a set of 
screen format commands. These include 
commands to cycle through a fixed set of 
screen display colors, toggle auto indent 
on and off, change cursor type, and save 
a copy of the editor with the new default 
settings. 

The F6 function followed by a single 
letter will execute one of five miscella¬ 
neous commands. For example, F6-G 


The Norton Editor can act 
on two separate files at 
once. 


prompts you for the line number to jump 
to, F6-M finds the matching punctuation 
symbol, and F6-T tests the two windows 
for differences. In split-screen mode this 
command causes the editor to compare 
the data in the two windows, from the 
current cursor position to the end of the 
edit buffer. The results of the comparison 
are reported in the program status line at 
the bottom of the screen. 

The F7 function key controls various 
commands for printing text on the line 
printer. These include printing the entire 
edit buffer, printing a marked block of 
text, issuing a form feed, and setting the 
left margin for the printer. 

The F9 function key loads the DOS 
command processor. 

The F8 and F10 function keys haven’t 
been assigned. 

A number of additional commands are 
available in the editor. Especially con¬ 
venient is the Find or Find-and-replace 
command. The search can be case sensi¬ 
tive or insensitive, in the forward direc¬ 
tion if the initiating command is Alt-F, 
or in the reverse direction in response to 
Ctrl-F. As soon as you enter the com¬ 
mand, the editor prompts you for the 
search string. If you want to replace the 
string, you simply type another Alt-F or 
Ctrl-F to terminate the search string, fol¬ 
lowed by the replacement string. When a 
matching string is found in the text, you 
are asked if you want to replace the 
string. If you respond with an asterisk, 
all remaining occurrences of the string 


are replaced without any further prompt¬ 
ing. 

Documentation for the Norton Editor 
consists of a single 48-page staple-bound 
manual. Although not the most sophisti¬ 
cated publication on the market, it covers 
the basic operation of the editor in suffi¬ 
cient detail. However, I found the editor 
so easy to use that the manual was al¬ 
most unnecessary. 

I found the Norton Editor to be an ex¬ 
cellent product. It is small, very fast, and 
will probably meet more than 90 percent 
of the needs of the average computer 
programmer. Although it does not have 
the power and flexibility of high-end 
programmer’s editors, its price and ease 
of use make it an attractive alternative. 

The Norton Editor, Version 1.3C, is 
available for $75 from Peter Norton 
Computing, 2210 Wilshire Blvd., Suite 
186, Santa Monica, CA 90403, phone 
(213) 319-2010. 
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Multi-Edit 

Another entry in the field of low-cost 
programmer’s editors, Multi-Edit from 
American Cybernetics, is an outstanding 
value. It contains virtually all of the fea¬ 
tures of the more expensive editors, but 
sells for half the price. 

Installation of Multi-Edit requires sim¬ 
ply copying the program disk to your 
hard disk and setting the search path to 
include the directory containing the ex¬ 
ecutable image. All of the setup and con¬ 
figuration is performed from within 
Multi-Edit. You can customize the pro¬ 
gram at any time, including in the middle 
of an editing session. You select options 
from an exceedingly friendly menu sys¬ 
tem. Options include tailoring the com¬ 
piler command line, remapping the key¬ 
board layout, selecting screen colors, and 
controlling indentation and tab stops. 

Multi-Edit contains a number of 
unique features not found in other pro¬ 
grammer’s editors. Mouse support is 
built into the editor. You can turn it on or 
off and control the sensitivity through 
the installation menus. The inclusion of a 
line-drawing feature permits the use of 
extended graphic characters, while a 
single keystroke displays a table of AS¬ 
CII character codes. 

Possibly the most useful of the unique 
features is the built-in calculator. It uses 
standard algebraic notation and supports 
floating point, decimal, hex, and binary 
formats. It also includes the logical op¬ 
erations AND, OR, and XOR. For any¬ 
one who has the annoying habit of con¬ 
tinually misplacing his or her program¬ 
mer’s calculator, this feature should 
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prove a valuable time saver. 

While adding new text to an existing 
file or changing existing text within a 
file, Multi-Edit changes the text color 
from the normal text color. I found this 
feature useful when trying to remember 
just what changes I had made to the file 
during a particular session. 

Multi-Edit includes a context-sensitive 
help system useful for beginning users or 
for explaining the more esoteric features. 
The bottom row of the screen also dis¬ 
plays the labels of the current commands 
assigned to the function keys. When you 
hold down the Control, Alt, or Shift key, 
these labels change to reflect the new 
commands assigned to those function 
keys. 

Another interesting feature in Multi- 
Edit is the DOS Directory Shell com¬ 
mand. You can use it to perform a num¬ 
ber of DOS file commands without in¬ 
voking the Command.com shell. It 
proved useful for examining the contents 
of different directories without actually 
changing the current directory. You can 
also use it to load a new file for editing 
or to execute a file if the file extension 
happens to be .exe or .com. You can also 
print a disk file using the DOS back¬ 
ground print spooler, Print.com, without 
actually loading the file. 

Multi-Edit supports compilation with¬ 
out leaving the editor. You can custom¬ 
ize this feature to work with a large num¬ 
ber of different languages. It works by 
outputting error messages to a known 
file, then reading the file, parsing the er¬ 
ror messages, placing the cursor at the 
offending line in the source file, and dis¬ 
playing the error message. I used the fea¬ 
ture with the Microsoft C, Version 5.1, 
compiler and it worked without a prob¬ 
lem. 

The Undo operation in Multi-Edit is 
comparable with the same feature in 
other programmer’s editors. A separate 
undo buffer assigned to each file holds a 
maximum number of operations between 
0 and 65,767, setable from the installa¬ 
tion subsystem. The only operations you 
cannot undo are DOS shell commands, 
disk file operations, and window func¬ 
tions such as sizing or window deletion. 

Multi-Edit includes a keystroke macro 
facility. To record a sequence of key¬ 
strokes, you first strike the <ALT F10> 
key. You then continue editing as you 
would normally, while the system re¬ 
members each keystroke. When you hit 
<ALT F10> again, Multi-Edit prompts 
you for the key you wish to assign to the 
macro. You play back the sequence of 
keystrokes by simply striking the as¬ 
signed key. Once you have recorded a 
keystroke macro, you can then edit the 
macro and even convert it into the Multi- 
Edit macro language source code. 


The Multi-Edit macro facility is a 
compiled programming language similar 
to Pascal in its syntax. It includes charac¬ 
ter, string, integer, and floating-point 
data types; user-definable local and 
global variables; and the If Then, and 
While Do program constructs. You can 
also pass parameters to a macro and re¬ 
turn values from the macro. The lan¬ 
guage includes a rich set of built-in func¬ 
tions for manipulating strings, manipu¬ 
lating text, performing block operations, 
controlling cursor movement, and inter¬ 
facing with the screen and the system 
keyboard. 

You can execute macros in a number 
of different ways. You can invoke them 
from the ‘Run Macro’ function, execute 
them by pressing the key to which a 
macro is assigned, or invoke them from 
another macro. You can execute any 
macro when you start Multi-Edit by in¬ 
cluding its name as an option on the 
DOS command line. In addition, if a 
macro named Startup.mac is found in the 
current directory or in the Multi-Edit di¬ 
rectory, it is executed when Multi-Edit 
first starts. 

When you select a programmer’s edi¬ 
tor, often the small features make it the 
most useful. The many extra features 
found in Multi-Edit, together with the 
low price, make it one of the most pleas¬ 
ing entries in a highly competitive field. 

I highly recommend you take a look at 
what it has to offer. 

Multi-Edit, Version 3.02a, is available 
from American Cybernetics, 1228 N. 
Stadem Dr., Tempe, AZ 85281, phone 
(602) 968-1945, for $99. 
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Summing up 

All of the editors presented in this re¬ 
view are excellent. They are fast, power¬ 
ful, and easily configured to suit your 
needs and personal preferences. BRIEF, 
Epsilon, Multi-Edit, and Vedit Plus are 
also easily extended with the built-in 
macro and language extensions. These 
features allow the most demanding pro¬ 
grammer the freedom to tailor the editor 
to perform virtually any task required 
during the software development pro¬ 
cess. Even the Norton editor, although 
clearly not as powerful and extendable as 
the other editors, offers a good price/per¬ 
formance ratio and should not be ig¬ 
nored. A large percentage of professional 
programmers might find it satisfies all of 
their needs. 

Choosing the right programmer’s edi¬ 
tor is not an easy task. However, a 
choice of any one of the editors reviewed 
here will not leave you disappointed. 
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System manages software implementations 


Athena Systems has announced a 
software implementation management 
system for distributed software develop¬ 
ment on networks of Unix-based work¬ 
stations and file servers. Paraview 
reportedly uses network operating and 
window management systems, such as 
Network File System and either X Win¬ 
dow System or Sunview, on a range of 
Unix platforms, such as those from 
Digital Equipment, Mips Computer, 
Solbourne, Sony, and Sun 
Microsystems. 

According to the company, Paraview 
automatically captures complete project 
data configurations and network loca¬ 
tions, the process for building the soft¬ 
ware, and identified software problems. 
The project information is contained in 
views, which the company calls logical 
references to the real data. Developers 
working on the same view of the project 


Editor assists developers 

Language Processors has announced 
the CoEdit integrated editor for use 
with the company’s compilers or with 
other Unix software. The language- 
sensitive editor has a built-in compila¬ 
tion command, an expression evaluator, 
a precompile syntax checker, and an on¬ 
line help system. 

Other CoEdit features include pop-up 
menus and unlimited windows, a macro 
language with its own compiler and 
debugger, context-sensitive help, key¬ 
word templating, automatic back¬ 
ground saving, and undo capabilities. 

Initially, CoEdit will run on Intel 
80386-based systems running Interac¬ 
tive’s 386/ix Unix operating system. 
Scheduled to ship in the second quarter, 
CoEdit costs $349. 
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automatically receive changes to the 
project data as they occur. 

Paraview reportedly provides for par¬ 
allel software development, availability 
of complete project data and the build 
process to individual members of the 
development team, and resolution of 
software problems through a software 
problem, reporting, and tracking sub¬ 
system. 

Other capabilities include automated 
network-wide builds of libraries and 
executables, automatic file dependency 
resolution network wide, milestone 
marking and audit trails, multilevel 
security for access to project data, and 
compatibility with Unix shell-based 
development tools. 

Paraview costs $11,000 for a 10-user 
license. 

Reader Service 30 


Data General has based its Aviion 
computer systems and workstations on 
Motorola’s 88000 RISC microproces¬ 
sor. The systems use the DG/UX 4.1 
revision of the company’s Unix operat¬ 
ing system. 

The midrange system/server comes 
with one or two processors in deskside 
or rackmount versions. Both include a 
10-slot VME-compatible chassis, up to 
108 Mbytes of error-correcting code 
memory, and cartridge and reel-to-reel 
tape options. The deskside version 
includes up to 2 Gbytes of mass storage; 
the rackmount version contains up to 16 
Gbytes of mass storage through dual- 
ported 8-inch SMD disks. 

Synchronous controllers and the 
VMEbus Ethernet controller provide 
wide and local area communications. 
Terminal services host adapter boards 


XL2 verifies prototypes 

Integrated Measurement Systems is 
shipping the Logic Master XL2 proto¬ 
type verification system. First intro¬ 
duced in August of 1988 with 80-MHz 
rates, the XL2 now supports full 
100-MHz bidirectional data rates. 

The XL2 verifies devices with up to 
448 bidirectional pins or 896 indepen¬ 
dent channels. It reputedly can test elec¬ 
tronic components at full speed under 
all conditions. 

The system consists of the tester and 
the software to run it. The software 
supplied with the system provides links 
between the tester and the user’s con¬ 
troller machine. The controller can 
range from a PC up to a DEC VAX. 

The XL2 ranges in price from 
$80,000 to $800,000 depending upon 
the capacity. 
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handle up to 512 RS-232 asynchronous 
connections. They connect up to 128 
asynchronous devices through cluster 
controller boxes. 

The workstations support from 4 to 
28 Mbytes of memory in a pedestal 
enclosure. They use a single multilayer 
board containing an 88100 CPU and 
FPU, two 88200 CMMUs, and mono¬ 
chrome or color graphics hardware 
coprocessors. The workstations come 
standard with interfaces for a PC-AT 
keyboard, a three-button optical 
mouse, an SCSI port, a parallel port, a 
serial port, and 802.3 Ethernet. 

DG/UX 4.1 implements the 88open 
Binary Compatibility Standard. 

System/server prices start at $52,000. 
Workstation prices start at $7,450. 
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System measures path coverage for C 


Tcat-Path/C from Software Research 
analyzes path coverage of C programs. 
According to the company, the system 
permits detailed analysis of actual paths 
through groups of C programs. 

Tcat-Path/C consists of user-callable 
components. Its tools extract detailed 
structure information, generate sets of 
all possible paths for each program unit 
(the tester can enter a list of mutually 
exclusive logical branches to eliminate 


Ariel has announced a symbolic 
debugger for Motorola’s 56001 digital 
signal processing chip. Bug-56 features 
pull-down menus, full-screen symbolic 
debugging, symbolic breakpoints and 
traces, symbolic patch assembly, a file 
browser, direct modification of control- 
register bits, and on-line help. 

Bug-56 can update its register display 
and make changes to registers or mem¬ 
ory while programs run at full speed, 
according to the company. The DSPio 
features provides built-in hooks to MS- 


impractical paths), automatically instru¬ 
ment the C programs and collect path 
coverage data, and analyze and report 
on path coverage. 

Tcat-Path/C runs on Unix, MS-DOS, 
and OS/2 platforms. A single-user MS- 
DOS version costs $1,950, while the 
single-workstation Unix license costs 
from $1,950 to $11,000. 
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DOS. DSPio operations are reportedly 
transparent to the 56001 program under 
development. 

A macro system helps programmers 
automate tasks. 

Bug-56 includes the Degmon resident 
monitor, which occupies 64 words of 
program memory. Degmon allows the 
debugger to use the resources of the 
56001. 

Bug-56 costs $395. 

Reader Service 35 


Pro-C generates C source code 

Version 1.3 of Pro-C from Vestronix 
(formerly Chancelogic) is a C source- 
code applications generator for MS- 
DOS, QNX, Xenix, and Unix. 

Pro-C capabilities encompass struc¬ 
ture and data definition, including mul¬ 
tifile cross references; WYSIWYG 
screen, menu, and report program 
generation; old master in/new master 
out and on-the-spot update program 
generation; system documentation 
generation; and context-sensitive help. 

New features include windows, a 
dBase III interface, the ability to view 
multiple records, new help features, and 
color support. 

The windows feature lets developers 
create applications with moving win¬ 
dows, multiple windows, dynamically 
sized windows, scrolling regions, and 
subscreens. 

The new help functions include 
dynamically resizable help windows and 
the ability to edit the help text supplied. 

In addition to color support, Version 
1.3 has a redesigned front end. 

Pro-C costs $495. Upgrades are avail¬ 
able to owners of Version 1.2. 
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Symbolic debugger cleans up 56001 code 


RISC development tool solves 

Step Engineering has announced a 
second-generation RISC development 
tool, the Adapt II 29K, which the com¬ 
pany claims provides hardware 
resources capable of solving Class II 
RISC problems involving hard¬ 
ware/software integration. The tool 
supports 40-MHz Am29000-based sys¬ 
tems with nonintrusive in-circuit emu¬ 
lation. 

The problem-solving hardware 
resources include a breakpoint facility, 
an interface to external logic state 
analyzers, an additional 32 bits of logic 
state analysis outputs, and a ROM 
simulator pod for debugging and patch¬ 
ing of ROM-based code. 

The Adapt II 29K consists of an 
instrument chassis with cable and pod 
assemblies. It is plugged into the target 
system and controlled by a user- 
provided PC or ASCII terminal. 

The system’s ROM simulator consists 
of RAM memory in a pod with a cable 
for attachment to the user’s system 
through the memory sockets. The RAM 
simulates the user’s ROMs, permitting 



integration problems 


Step Engineering’s Adapt II 29K supports 40-MHz Am29000-based system devel¬ 
opment with nonintrusive in-circuit emulation. 


updates with program patches. and librarian, an ANSI C compiler, and 

The Adapt II 29K costs $13,500. The a source-level debugger, 
system comes with a hex debugger, a 

macro assembler with linking loader Reader Service 37 
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HP adds 20-MHz 386-based model to Vectra family 


Hewlett-Packard has added a 
20-MHz desktop PC based on the Intel 
80386 microprocessor to its HP Vectra 
family. The QS/20 PC can be con¬ 
figured with up to 16 Mbytes of RAM 
on the processor board and has three 
mass-storage shelves and seven expan¬ 
sion slots. 

The QS/20 features a dual-bus archi¬ 
tecture. The 20-MHz, 32-bit bus 
accesses memory and handles operating 
software. The 8-MHz, 16-bit I/O bus 
handles add-in and peripheral devices. 

The new PC also supports LIM EMS 
4.0 and is compatible with OS/2, Win¬ 
dows/386 Presentation Manager, and 
SCO Xenix 386. 

The Vectra QS/20 comes with serial 
and parallel ports, disk-cache software, 
and HP terminal-emulation software. 

Model lOe D1420A features a 
5%-inch, 1.2-Mbyte floppy disk drive. 

Model 15e D1427A has a 3^-inch, 

1.44-Mbyte floppy disk drive. Both 
models cost $4,495. 

Model 46 D1422A has a 5/-inch 
floppy disk drive, a 40-Mbyte hard disk 
drive, and a VGA card. Model 47 
D1442A has a 3X-inch floppy disk 
drive, 40-Mbyte hard drive, and VGA 
card. Both models cost $5,995. 

Reader Service 38 Hewlett-Packard’s new Vectra QS/20 PC employs a 32-bit 80386 CPU. 



PC-based IEW/CWS generates Cobol applications from diagrammatic specs 


KnowledgeWare has added the PC- 
based lEW/Construction Workstation 
to generate Cobol applications from 
diagrammatic specifications created 
with the IEW/Design Workstation. The 
company claims IEW/CWS can gener¬ 
ate all of the Cobol source code, data¬ 
base schemas, database definitions, 
data access routines, screen maps, and 


Hymarc says that its Hyscan 45C 
laser digitizer permits designers to move 
rapidly from prototypes to the CAD 
environment. The non-contact laser 
reportedly maps objects at 10,000 
points per second. 

The digitizer mounts on manual or 
servo-driven coordinate measurement 
machines. It maps a prototype by scan¬ 
ning the surface and digitizing on a grid 
as fine as 0.001 x 0.001 inches. The 3D 
computer model is displayed in real 
time on the system monitor and trans¬ 
ferred to CAD over Ethernet. 


system documentation for an appli¬ 
cation. 

IEW/CWS runs under DOS and uses 
a Windows/Presentation Manager 
interface with pull-down menus, multi¬ 
ple windows, and mouse-driven color 
graphics. It generates ANSI standard 
Cobol or Cobol II source code. 

According to KnowledgeWare, the 


of prototypes to CAD models 

The patented synchronized scanning 
technique offers a larger field of view, 
decreased triangulation baseline, and 
improved ambient light immunity, 
according to the company. Menu-driven 
software allows the operator to set scan¬ 
ning control parameters and data reduc¬ 
tion criteria. 

The system consists of a controller, 
scanner, user interface, graphics dis¬ 
play, scanning control pendant, and 
software. 

The controller incorporates a Motor¬ 
ola 68030 processor running at 20 


product is integrated with the com¬ 
pany’s other life-cycle-development 
workstation tools. This reputedly per¬ 
mits the code generator to directly 
implement the end user’s requirements 
in the generated application. 

IEW/CWS costs $8,625. 
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MHz, a Motorola DSP 56000 proces¬ 
sor, a laser, a 100-Mbyte hard disk, a 
30-column data logger, and an Ethernet 
802.3 host interface. The user interface 
is a DEC VT220-compatible with a 
14-inch screen, while the graphics dis¬ 
play is a monochrome monitor with a 
12-inch screen. 

The software includes data acquisi¬ 
tion and camera control, operating, and 
calibration software. 

The Hyscan 45C costs $90,000. 
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Software integrates schematic capture and PCB layout 


Simulation environment 
evaluates designs 

Scientific and Engineering Software 
offers SES/workbench, which the com¬ 
pany calls a multilevel design evaluation 
and simulation environment. The soft¬ 
ware includes a graphical user interface 
called SES/design that reportedly 
allows designers to construct models of 
a system by using icons to specify com¬ 
ponents at multiple levels of abstrac¬ 
tion. The program automatically 
translates design models into its simula¬ 
tion language, SES/sim, which is a 
superset of ANSI C and C+ + . 

SES/workbench provides an environ¬ 
ment for top-down, multilevel design 
and allows modeling across several 
levels of resolution. It also has program 
library management capabilities, an on¬ 
line reference manual, and hypertext- 
based help features. 

The program runs on engineering 
workstations from Sun Microsystems, 
Digital Equipment, and Apollo, as well 
as minicomputers and supercomputers. 
SES/workbench prices start at $28,000 
plus maintenance on workstation 
platforms. 
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Phase Three Logic has integrated 
schematic capture and printed circuit 
board layout in its CapFast CF/PCB 
software package. The product includes 
the company’s CF3000 schematic design 
software and the OEM version of CAD 
Software’s PADS-PCB printed circuit 
board layout tool. The two systems are 
integrated through forward and back¬ 
ward annotation capabilities. 

The CF3000 software features 
schematic and symbol editors; a symbol 
library; plotting, packaging, and parts- 
list programs; PCB netlist interfaces; 


Systems Effectiveness Associates 
claims that its RAMCAD software 
bridges the gap between the company’s 
reliability and maintainability (RAM) 
analysis software and CAD systems. 
RAMCAD accepts parts lists and bills 
of material data in the form of ASCII 
files from CAE/CAD systems and 
transfers the data to the analysis soft¬ 
ware to get reliability and maintainabil¬ 
ity predictions. 


Spice and Hilo-3 simulator netlist inter¬ 
faces; a simulation grapher; and the 
Programmable Netlist Library. 

The CF/PCB layout tool has CAD 
design capabilities and a set of auto¬ 
matic design aids. It features a layout 
database, automatic and interactive 
component placement, track routing, 
and automatic design rule checking. 

CapFast CF/PCB runs on the IBM 
PC-AT, PS/2, and compatibles with 
EGA graphics. It costs $1,995. 
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RAMCAD runs on IBM-compatible 
PCs, VAX and Micro VAX II machines, 
and Apollo Domain workstations using 
the MS-DOS, VMS or MicroVMS, or 
Domain operating systems, respectively. 
The program also requires REAP 
(Reliability Effectiveness Analysis Pro¬ 
gram) or REAPmate. Licenses start at 
$ 1 , 000 . 
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RAMCAD links CAD and analysis software 


Cray builds up Y-MP line of 
supercomputers 

Cray Research has extended its line of 
Cray Y-MP supercomputers to 19 stan¬ 
dard models featuring one, two, four, 
or eight processors for prices ranging 
from $5 million to $23.7 million. A 
CPU with a 6-ns clock cycle is imple¬ 
mented on a single multilayer module, 
allowing modular upgrading of systems. 
Three frame sizes are offered, with two, 
four, or eight CPU slots. 

Systems can be configured with 16, 

32, 64, or 128 million words of mem¬ 
ory, depending on frame size. 

The Y-MP systems can run in X-MP 
compatible mode. 

Cray Y-MP systems come with the 
Unicos operating system, based on 
AT&T’s Unix System V with Berkeley 
extensions and other enhancements. 

The systems also come with Fortran, C, 
and Pascal compilers; debugging and 
program maintenance tools; and utili¬ 
ties and libraries. Ada and Common 
Lisp compilers are available, as are 
communications software and 
hardware. 



Cray Research’s Y-MP8 supercomputer, shown here, has slots for eight CPUs. 

Y-MP systems with eight-slot frames all three frame sizes are scheduled for 
are available. Frames with two and four the second quarter of 1990. 
slots are scheduled for the third quarter. 
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1C Announcements 


Company, Model, Function 


Analog Devices 
AD849, AD848 
Op amps 


Burr-Brown 
OPA2107 
Op amp 


Burr-Brown 

SDM872/3 

DAS 


Hycom 
HD-4824 
Modem chip set 

Integrated Device 
Technology 
IDT 6178 
SRAM 

Integrated Device 
Technology 
IDT 71586 
SRAM 

Intel 

85C508 

PLD 

Motorola 

MCM6270J25/35, P25/35 
SRAM 


National Semiconductor 

DP83910 

LAN chip 


National Semiconductor 

NS32GX32 

Processor 


Precision Monolithics 
OP-80GP 
Op amp 

Weitek 

33-MHz Abacus 3167 
Numeric coprocessor 

Weitek 

XL-8832 

Processor 


Comments 


R.S. No. 


Totally compensated AD849 has 725-MHz gain bandwidth for gains >25. Partially compen- 120 
sated AD848 has 50-MHz GBW for gains >5. Both require typical 5-mA supply current. 

They are available over three temperature ranges, in plastic 8-pin miniDIP, ceramic DIP, and 
SO packages. Cost (100s): from $2.95. 

A dual-precision, unity gain stable op amp. Typical 8-nV/VHz noise at 10 KHz, offset volt- 121 
age of 500 pV max, input bias current of 5 pA max, min slew rate of 13 V/ps, and settling to 
0.01% in 2 ps. Comes in 8-pin plastic DIP, metal TO-99, and plastic SOIC packages. Cost 
(100s): from $5.60. 

Two 12-bit data acquisition systems with 50-KHz throughput rates. SDM872 has 16 single- 122 
ended input channels; SDM873 has 8 differential channels. They include an input MUX, in¬ 
strumentation amp, sample/hold amp; and A/D converter. They come in 68-lead PGA and 
68-pin LCC packages. Cost (100s): from $119.23. 

A full-duplex, CCITT V.22 bis modem chip set that operates at 4,800, 2,400, 1,200, and 300 123 

bps. Features Hycom’s extended baud rate. Based on a digital signal processor and an inte¬ 
grated A/D chip. Sampling now. No prices given. 

A TTL 4Kx4 cache-tag static RAM with a 12-ns address-to-match time and a single-pin 124 
block reset that clears RAM data in less than two cycles. Comes in 22-pin plastic and her¬ 
metic DIP and 24-pin SOJ packages. Cost (100s): $94.42 (plastic DIP). 


A 4Kxl6 CacheRAM optimized to work with Intel’s 82385 cache controller in 33-MHz 125 
80386 systems. Has a 25-ns access time, on-chip address latch, and 10-ns output enable time. 
Comes in 40-pin plastic and ceramic DIPs and 44-pin PLCCs. Cost (100s): $41.40 (25 ns, 
plastic DIP). 

A programmable address decoder for 25-MHz and faster pipelined micros. Has an on-board 126 
latch, max propagation delay of 7.5 ns, 16 direct inputs, a P-term array, and 8 output latches. 
Comes in a 28-pin plastic DIP. Sampling now. Cost (10,000s): $12.50. 

A 4Kx4 fast SRAM, with 25-ns address/chip enable speed and 12-ns output enable speed for 127 
MCM6270J25/P25 and 35- and 14-ns speeds, respectively, for MCM6270J35/P35. 
MCM6270J25/35 comes in SOJ packages, and MCM6270P25/35 comes in 22-lead PDIPs. 

Cost (100s): from $4.58 (MCM6270P35) to $6.90 (MCM6270J25). 

A serial network interface chip that replaces the DP8391. Meets power requirements of Eth- 128 
emet add-in boards for laptop computers. Provides Manchester data encoding and decoding 
functions for Ethernet LANs. Compatible with the proposed lOBaseT standard. Comes in 24- 
pin DIPs and 28-pin PLCCs. Cost (100s): $19.50 (DIP), $20.75 (PLCC). 

A 32-bit microprocessor for embedded systems. Provides on-chip bitblt instruction primi- 129 
tives and logic, stack instruction syntax for PostScript execution, and two-way set associa¬ 
tive data cache for character generation. Comes in a 175-pin PGA. Sampling now. Cost 
(1,000s): from $99 (20 MHz). 

An op amp featuring input currents of 0.2 pA at +25°C and 0.5 pA at +85°C, power dissipa- 130 
tion of 1 mW, single-supply operation, and inputs protected against 700V of static discharge. 
Comes in 8-pin plastic DIPs for extended industrial temperature range. Cost (100s): from $2. 

A 33-MHz version of the Abacus 3167 numeric coprocessor. An option for 33-MHz 80386- 131 

based systems. Replaces Intel’s 80387 processor. Samples available now to OEMs, with pro¬ 
duction in July. Cost: $1,695. 

A floating-point RISC processor for OEMs. Provides 20 Mflops performance and single-pre- 132 
cision Digital F-format floating-point support in a three-chip set: XL-8136 program sequenc¬ 
ing unit, XL-8137 integer processing unit, and XL-3832 floating-point unit. Each comes in a 
144-pin PGA. Cost (1,000s): $750. 
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Engineering, Manufacturing, and Distributed Computer Systems. 

This conference focuses on the problems, issues and solutions of integrated system design, implementation 
and performance. Integration technologies will be emphasized with a focus on computer-aided software 
engineering, collaborative and distributed systems, and computer integrated manufacturing systems. The 
conference will provide an international and interdisciplinary forum in which researchers and practitioners 
can share novel research, engineering development and strategic management experiences. Papers 
should deal with recent work in theory, design, implementation, utilization and evaluation of integrated 
systems. Topics to be addressed include, but are not limited to: 

Computer-Aided Software Engineering • Knowledge-Based and Expert Systems • Software Development 
Technologies • Software Bases and Management • Software Specifications • Design and Prototyping 

• Tools and Methodologies • Computer-Aided Design/Computer-Aided Manufacturing • Computer 
Integrated Manufacturing • Manufacturing/Engineering Computing • Automated Storage and Retrieval 
System • Pattern Recognition and Computer Vision • Manufacturing/Engineering Databases • 
Distributed Processing Systems • Data Communications and Computer Networks • Protocols and 
Standards • Resource Allocation and Scheduling • Fault-Tolerant Computing • Reliability and Quality 
Assurance • Modeling and Performance Evaluation/Measurement • Collaborative Systems 

• Organizational Information Resources • Project Planning and Management • Database Management 
Systems • Artificial Intelligence Techniques • Man-Machine Interfaces. 

Information and Instructions for Authors: Authors are cordially invited to submit original technical papers 
to the program chairman no later than July 25, 1989. All papers must be in English, typed in double spaced 
format, and may not exceed 6,000 words. Each submission should provide a cover page containing 
author(s), affiliation(s) complete address(es), identification of principal author, and telephone number. Also 
include SIX copies of complete text with a title and abstract. Notice of acceptance will be mailed to the 
principal author(s) by September 15, 1989. If accepted, the author(s) will prepare the final manuscript in 
time for inclusion in the conference proceedings and will present the paper at the conference. Authors of 
accepted papers must sign a copyright release form. 


Please send SIX copies of your paper(s) to: 

Professor Peter A. Ng, Program Co-Chairperson 
Department of Computer and Information Science 
New Jersey Institute of Technology 
Newark, NJ 07102, U.S.A. 


Paper Arrival Deadline: July 25,1989 
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CONFERENCE COMMITTEE 


Conference Co-Chairpersons: Larry Seifert, AT&T, 
Raymond T. Yeh, Syscorp Inc. 

Program Co-Chairpersons: Peter A. Ng, NJIT; 

C.V. Ramamoorthy, UC Berkeley 

Local Arrangement Chairperson: Fred Poluhovich, 
Chemical Bank 
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Software Engineering: Leszlo A. Belady, MCC 
Manufacturing: Michael Kelly, NJIT and DARPA 
Distributed Systems: Erich Neuhold, GMD 
Data Management. P. Bruce Berra, Syracuse U. 
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Microsystem Announcements 


Company, Model, Function Comments R.S. No. 


Analogic 
DVX 2502 
DAS board 


Asante Technologies 
MacCon II/E 
Ethernet interface card 


C&C Technology 

MacVEE 

Bus interface 


Commodore 
A2286D Bridgeboard 
Coprocessor 


Data Translation 

QuickCapture 

Frame grabber for PS/2 


DY-4 Systems 
SVME-740 
LAN controller 

Heath/Zenith 
SWS-4386 
Industrial computer 


Jovian Logic 
Sylvia 

Video input adapter 


Laser Magnetic Storage 
CM 212 
CD-ROM drive 

National Semiconductor 

Maccelerate 

Bus board 

PCQT AB 
PC/QT 

Industrial computer 

Univision 
UXL-1000 
Array processor 


Single-board computer 


A VME/VXI-compatible 8-channel data acquisition system board with 16-bit resolution. Built 
on a 6U VME card. Has a common mode rejection ratio greater than 100 dB at 60 Hz. In¬ 
cludes a 16-bit, 200,000 conversion/s sampling A/D converter. Operational control through a 
Unix V software driver. Cost: $3,700. 

An Ethernet interface card for the Apple Macintosh II. Register-level compatible with 
Apple’s Ethertalk interface card. Provides 32-bit data transfer and compliance with NuBus 
PC form and IEEE 802.3 standards. Supports up to 100 nodes and 305 meters/segment. Cost: 
$595. 

A card set that connects the Apple Macintosh II to VMEbus or CAMAC bus systems. Maps 
devices into the Mac’s 68020 4-Gbyte memory address space. Cost: $1,250 for Micron A410 
(Mac II interface), $1,175 for MacVEE V370 (VMEbus controller), $1,575 for Mac-CC 392 
(CAMAC controller), $125 for cable set. 

A coprocessor card that gives Amiga 2000 computers compatibility with AT-class MS-DOS. 
Plugs into the Amiga’s Bridgeboard expansion slot. Contains an 8-MHz 80286 chip, 1 Mbyte 
of RAM, and a socket for an 80287 chip. Comes with a 1.2-Mbyte 574-inch disk drive. Cost: 
$1,599. 

A version of the 256-gray-level frame-grabber board and software foi IBM’s PS/2 MCA mod¬ 
els and compatibles. Plugs into a PS/2 expansion slot and connects to video equipment with 
RS-170, PAL, CCIR, and NTSC video formats. Comes with QuickCapture Application Inter¬ 
face software. Cost: $2,595. 

A LAN controller for the VMEbus. Contains a 10-MHz 68010 microprocessor, 512 Kbytes of 
dual-ported DRAM, and 128 Kbytes of EPROM on one card. Includes a location monitor, 

BIT, and bus isolation mode. Optional TCP/IP firmware. Cost: $2,223; $3,889 with TCP/IP. 

An IBM PC-AT-based industrial computer with a 16-MHz 80386 CPU with zero wait states, 

1 Mbyte of RAM expandable to 16 Mbytes, a 40-Mbyte Winchester drive, a 1.2-Mbyte 574- 
inch floppy disk drive, and a 1.4-Mbyte 372-inch floppy disk drive. Has five expansion slots, 
security lock, and override switch. Cost: $7,500. 

A non-real-time video input adapter for PC bus machines (Sylvia/PC) and Micro Channel 
computers (Sylvia/MC). Resolutions from 320x200 to 640x480. Accepts video input in 
monochrome, RGB, or composite color. Comes with support software. Cost: $395 (Sylvia/ 
PC). 

A half-height CD-ROM drive with an embedded SCSI interface. Features a MTBF of 40,000 
hours, typical access time of 400 ms, and a 64-Kbyte buffer with caching capabilities. Targets 
OEMs. Cost: $875. 

An HPC16083 microcontroller-based, NuBus-compatible, SCSI bus controller board for 
Apple Macintosh II and IIX PCs. Stores and retrieves data through a DMA technique. Comes 
with software drivers for A/UX and the standard Mac operating system. Cost: $595. 

An industrial PC with externally mounted AC/DC converter power source and two built-in 
batteries. Features 80 80286 processors, 16-MHz clock frequency, space for two disk or tape 
drives, and two hard disks (40, 100, or 350 Mbytes). No price given. 

An array processor for IBM AT-type computers. Uses an NEC 32-bit floating-point proces¬ 
sor. Has on-board memory of 2Kx32-bit ROM, lKx32-bit data RAM, and 4Kx32-bit double- 
buffered SRAM. Comes with C callable software libraries. Cost: $1,950. 

An 80386-based single-board computer that runs at 16 or 20 MHz. Has a socket for an 80387 
math coprocessor. Configurable memory and I/O wait states. Includes two serial ports, one 
printer port, and one 24-line programmable I/O port. Supports up to 8 Mbytes of on-board 
DRAM. Cost: $2,046 (16 MHz, 1 Mbyte) to $5,155 (20 MHz, 8 Mbytes). 
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Semiconductor technology still far from limits, speaker Moore asserts 


Ware Myers, Contributing Editor 

The limits set by the laws of physics 
still appear to be several product gener¬ 
ations in the future, Intel Chairman 
Gordon E. Moore told the opening ple¬ 


nary audience at Compcon Spring 89 in 
San Francisco February 28. 

Even so, two more immediate obsta¬ 
cles threaten the phenomenal growth 
rate of the semiconductor industry, 
Moore said. One is finding markets to 


absorb worldwide production running 
at the rate of millions of transistors per 
year per consumer. The other is whether 
participants in the industry want to con¬ 
tinue to invest at this headlong rate. 

Hasan AlKhatib of Santa Clara Uni- 


Logic synthesis meets VLSI design needs 


“The only way to manage the 
increasing complexity [of VLSI and 
ASIC design] is to step up to a higher 
level of abstraction,” Harvey C. 

Jones, president of Synopsys, Inc., 
maintained in an opening-day ple¬ 
nary session address at Compcon 
Spring 89 in San Francisco February 
28. “The way to do that is to enable a 
new design technology analogous to 
the ‘place and route’ technology of 
the early 1980s. That new technology 
is logic synthesis.” 

Later, in a conference paper, 
Howard A. Landman of Sun 
Microsystems agreed, saying that 
“1988 may be remembered as the 
year logic synthesis became com¬ 
mercially practical.” 

In another paper, Jim Straus of 
Exemplar Logic added “Recent 
advances in synthesis tools have 
made practical the automatic synthe¬ 
sis of logic for commercial appli¬ 
cations.” 


What logic synthesis is. In 1979, 
the semiconductor industry was 



Harvey Jones of Synopsys addressed 
the February 28 plenary audience at 
Compcon. 


packing from 1,000 to 10,000 gates on 
a chip, Jones recalled. Design was 
being managed at the layout level. 
Companies had about 1 MIPS of 
computing resources per 20 
engineers and were verifying design 
in prototypes. 

By 1989, density has moved up to 
the 10,000 to 100,000 gates per chip 
level, Jones said. Companies want to 
manage design at the register- 
transfer level. There are up to 5 MIPS 
per engineer. Verification is being 
done by simulation. 

The design tools at the register- 
transfer level are labeled “logic syn¬ 
thesis.” Three levels of design, listed 
in Table 1, preceded it. 

Sometime in the late 1990s, a still 
later technology called “behavioral 
synthesis,” suitable for the million 
gate range, may be ready for auto¬ 
matic synthesis. 

“Most people, when confronted by 
the term ‘synthesis,’ think of what we 
call ‘translation,’ ’’ Jones observed. 
Translation converts a design repre¬ 
sentation in something that looks 
like a programming language into its 
gate-level representation, that is, a 
functional description into a logic 
diagram. 

“What has made logic synthesis a 
competitive reality is a body of tech¬ 
nology, coupled with the translation 
capability, that addresses optimiza¬ 
tion,” Jones said. Optimization starts 


with the existing design and 
minimizes chip area and signal-path 
delay under the environmental and 
process constraints that obtain. 

Expert designers have always 
optimized their designs, of course, 
but it has taken them days or weeks. 
Logic-synthesis tools can do the 
same work on powerful workstations 
in minutes or hours. “It is of very little 
value to effect a translation from 
high-level description to gates if that 
result is not fully competitive [in 
terms of chip area and circuit 
speed],” Jones insisted. 

Optimization reduces area, 
increases speed. A functional 
design, as originally conceived, rests 
out in the upper right corner of the 
area-path delay plane, as shown in 
Figure 1 Reduction of chip area 
reduces cost. Reducing the critical 
path delay speeds up the design and 
provides a marketing advantage. The 
designer’s goal is to find something 
near the optimum combination of 
these two variables. 

There are usually a number of 
alternatives within this design space. 

Working through them by manual 
methods takes days or weeks. More¬ 
over, designers with the needed skills 
are scarce. With automated logic 
synthesis and optimization, however, 1 

the designer can view a large number 
of alternatives in a matter of minutes 


Table 1. As chip density has multiplied, increasingly more powerful levels of 
design management have become necessary. 


Period 

Level 

Tool 

Gates/Chip 

Late 1960s 

Process 


10 

Mid 1970s 

Layout 

Mask Making 

100 

1980s 

Logic 

Place and Route 

1,000- 

10,000 
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versity served as general chair of Comp- 
con, the 34th annual IEEE Computer 
Society International Conference, with 
Kenichi Miura of Fujitsu America the 
program chair. The February 27-to- 
March 3 event at the Cathedral High 
Hotel comprised five invited speakers, 

14 tracks featuring 38 technical paper 
sessions and four panel discussions, and 
eight tutorials. 

An exponential life. The semiconduc¬ 
tor industry has lived an exponential 
life, according to Moore’s analysis. 

Feature size. From the original planar 
integrated circuit in 1959, feature size 


has been halved every six years. The 
minimum feature size of volume 
products today is about one micron, or 
one micrometer. 

“The demise of optical lithography 
has been predicted several times,” 
Moore observed. Many believed optical 
technology could not get below the one- 
micron level. “Now we are saying— 
maybe one-half micron. I even hear 
people starting to say 0.3 micron fea¬ 
ture size will be possible optically. We 
keep pushing alternative technologies 
further into the future.” 

Several years ago, when the thickness 
of the thin films in the active portions 
of the devices reached the 1,000-ang- 



Gordon Moore of Intel was the kickoff 
speaker at the first of three Compcon 
Spring 89 plenary sessions. 


to hours. The better alternative gets 
to market sooner, and this is a com¬ 
petitive advantage. 

Automated optimization of a 
45,000-gate graphics controller chip 
at Sun Microsystems led to produc¬ 
tion savings of $30 per 1C, or 
$330,000 in the first year, Jones said. 
The initial design contained 8,000 
gates of control logic. Optimization 
eliminated 3,000 gates, reducing the 
overall chip to 42,000 gates. 

In another example at Sun, 
reported by Landman, two engineers 
had spent two days manually speed¬ 
ing up a critical path to 20 nanose¬ 
conds from 25 nanoseconds, but 
seemed to be stuck at that speed. 
The goal of reaching 15 ns appeared 
to be beyond reach. After entering 
logic and timing constraints into a 
logic-synthesis program, Landman 
found a 12 ns solution in about 10 
minutes of workstation time. 

Harris Corporation found that nov¬ 
ice designers, on the one hand, 
reduced the area of their manual 
designs by 40 percent and path delay 
by 25 percent by using logic synthe¬ 
sis, according to Jones. Expert 
designers, on the other hand, did as 
well as the logic-synthesis system on 
area reduction and path delay, but at 
the cost of an average of five weeks 
work manually compared to two 
hours on the automated system. 

Jones compiled 12 case histories, 
covering experience with logic syn¬ 
thesis at computer, semiconductor, 
and aerospace companies on cir¬ 
cuits originally ranging from 112 to 
10,918 gates. The average reduction 
in chip area was 24.4 percent, with a 
range of 5 to 50 percent. The average 
improvement in critical path delay 
was 31.5 percent, with a range of 20 
to 65 percent. 

Experienced designers get best 
results. When the new generation of 
logic-synthesis tools began to 
appear in 1988, Sun Microsystems 
acquired and evaluated three of 


them, Landman reported to the con¬ 
ference. Most of the tools were at the 
beta level. He found it “surprisingly 
difficult to perform fair, ‘apples-to- 
apples’ comparisons between differ¬ 
ent [logic} synthesis systems.” He 
had to restrict comparisons to the 
least common denominator between 
the sets of capabilities. Also, the 
choice of what design to analyze had 
a large effect. 

Landman reported some details of 
his results in a conference paper, but 
they are highly qualified. In general, 
he concluded that the logic- 
synthesis systems “offer significant 
reductions in design time and 
improvements in the quality of the 
finished design.” However, “none of 
today’s tools do everything well, and 
it takes an experienced designer to 
get the best results from them.” 

Jones made a similar point, offer¬ 


ing as a “myth” the belief that “logic 
synthesis is a turnkey or push-button 
methodology that will displace the 
logic designer." Rather, "synthesis is 
an interactive application where an 
engineer can explore various alterna¬ 
tive implementations. Synthesized 
circuits are only as good as the qual¬ 
ity of the designer’s system architec¬ 
ture. An optimal solution is a 
function of the design constraints.” 

At the present state of logic syn¬ 
thesis, it serves CMOS designers 
very well, Jones said, but ECL optimi¬ 
zation is still in the research domain. 
Analog synthesis is another story. 
Present second-generation synthesis 
tools are capable of optimizing 
designs in the range of 25,000 to 
50,000 gates on currently available 
RISC workstations. Larger designs 
would have to be broken down into 
blocks of this size. —WM 



Figure 1. Logic synthesis enables the designer to explore a large number of alter¬ 
natives in a few minutes or hours of CPU time as compared to days or weeks of 
human effort. 
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strom level (one angstrom = 10' 4 
micron), Moore expected to find prob¬ 
lems, such as pinholes. They did not 
appear. Chemical forces evidently 
produced more uniform fill than he 
expected. 

Now the industry is down to the 
100-angstrom level. That is on the order 
of 10 molecular layers. At this point, 
quantum-mechanical tunneling through 
these structures starts to be important. 
“It will probably limit our finished 
films to the order of 50 to 75 ang¬ 
stroms,” he said. 

Electrical charge. The amount of 
charge needed to distinguish between 
two states has been reduced from 5 mil¬ 
lion to 100,000 electrons, a factor of 
two each generation. 

At about the 64K memory level, what 
appeared at first to be a fundamental 
limitation did appear. The DRAM 
devices were sensitive to alpha radiation 
and there was enough residual radiation 
from the packaging materials to cause 
errors. The devices had to be redesigned 
to put more charge into each cell, driv¬ 
ing DRAMs to the complicated technol¬ 
ogy of deep wells—three-dimensional 


structures making it possible to keep the 
density up. 

“If it had been any product other 
than DRAMs, it would not have had 
the attention required to get around this 
problem,” Moore said. “But DRAMS 
are the largest volume semiconductor 
product ever and the one that defines 
your technical prowess, so it drove peo¬ 
ple to consider these phenomenally 
complex structures.” 

Defect density. When a new technol¬ 
ogy goes into production, the defect 
density is relatively high. Then, the 
production organization works at 
reducing the defect rate. 

“After we got our yields up to a cer¬ 
tain level, we found it was advanta¬ 
geous to jump to a new level of 
technology with smaller dimensions, 
squeezing everything tighter. So defects 
went back to a higher level,” Moore 
explained. “We just kept going around 
this circle, never getting the defects in 
one generation entirely cleaned up 
before going on to the next.” 

In the early 80s, however, this cycle 
broke. “We found ourselves eliminat¬ 
ing defects faster than we were going 


Graphics supercomputers aid visualization 


Gaining insight through visualiza¬ 
tion into many classes of scientific 
and engineering problems involves 
computing, mapping, rendering, and 
displaying enormous quantities of 
data—often at the rate of more than 
100 megabytes per second. So said 
J. William Poduska, chief executive 
officer of Stellar Computer, in an 
invited plenary-session lecture March 
1 at Compcon Spring 89. 

For this purpose, Poduska said the 
traditional supercomputer has 
drawbacks—it is expensive, it is 
generally not available for interactive 
use by a single user, and the band¬ 
width between its computing ele¬ 
ments and the display is relatively 
narrow. 

Recent advances in VLSI technol¬ 
ogy enable the graphics supercom¬ 
puter to overcome these obstacles, 
at least for the low end of the visuali¬ 
zation market, Poduska continued. 

Its price—in the $100,000 range— 
brings it withih reach of the individ¬ 
ual senior scientist or engineer. Stel¬ 
lar’s graphics supercomputer solves 
the bandwidth problem by the liberal 
use of silicon—the bus between the 
storage elements and the computa¬ 
tional units, for example, is 512 bits 
wide. Moreover, the size of the scien¬ 
tific problems to be visualized can be 
enlarged by allocating the mass of 


the computations to a supercom¬ 
puter operating in batch or back¬ 
ground mode. Then the entire 
capacity of the graphics supercom¬ 
puter is devoted to the visualization 
task. 

After speaking, Poduska was 
presented the 1988 W. Wallace 
McDowell Award, the IEEE Computer 
Society’s highest technical achieve¬ 
ment commendation (see p.76 of the 
April 1989 issue of Computer). 


-WM 



William Poduska of Stellar Com¬ 
puter spoke before a Compcon ple¬ 
nary audience March 1. 


around the generations of technology.” 

Reduced defect density has profound 
implications. The designer is no longer 
limited to a small chip area. He can 
have a larger chip and put more devices 
on it. Over the years, chip size has 
increased from the 10-square-millimeter 
range to the 100 mm 2 range and is now 
reaching the 150 mm 2 range. 

The day before Moore spoke, Intel 
announced the i860 64-bit microproces¬ 
sor with a million transistors on one 
chip. In two years, he expects that num¬ 
ber to double. “If you travel ahead 
another 10 years, to the year 2000, you 
come up with 50 million transistors on a 
chip.” 

“In fact, it is starting to become 
practical to consider full wafers,” 
Moore said. The challenge really is to 
figure out what to do with all that capa¬ 
bility. “I suspect every logic function 
we have ever built can be put on one 
chip at that level of complexity.” 

Then, he smiled ruefully. “This is not 
the first time I have made this reserva¬ 
tion.” But applications continued to 
turn up and the industry continued on 
its exponential path. 

What market flexibility implies. In 

1968, the semiconductor industry 
produced about 10 9 transistors. By 
1988, that number was up to 10 15 . “The 
average slope of this curve is about a 
decade every three years, that is, 10 
times as many transistors as three years 
earlier,” Moore pointed out. Put 
another way, the number of transistors 
produced doubles every year. That is a 
series of the form 1, 2, 4, 8, 16, and so 
on. Each successive number of this 
series is equal to more than the sum of 
all the previous numbers. 

That means the industry had to find 
additional markets each year as large as 
the sum of all the previous markets. To 
do that, of course, means the price had 
to fall. It did—by a millionfold. 

To keep the industry on this curve, 
Moore figured that each man, woman, 
and child in the developed countries, 
having consumed a million transistors 
last year, would have to account for 
two million this year and four million 
next year. He himself acquired about 16 
million last year—in his boat, his home 
PC, and his office PC, and seemed 
pleased that he was ahead of the curve. 
“Did each of you consume his four mil¬ 
lion transistors per family last year?” 
he asked the audience. 

“Frankly, it is easier for me to see 
where the technology is going,” he said, 
“than it is to see those new markets that 
are going to use 10 16 or 10 17 transistors 
per year that we will require to keep this 
thing going.” 
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An expensive business. The cost of 
doing all this has been following its own 
exponential curves—up. Back in 1968, 
Intel developed two new technologies, 
silicon-gate MOS and Schottky bipolar, 
for about $2 million, Moore said. Now, 
the cost of developing a new technology 
is about $60 million. 

In the old days, the rule of thumb for 
the cost of one piece of equipment—one 
lithography machine, one bank of fur¬ 
naces, one evaporator—was $12,000 
each, he recalled. “The price of each 
piece has grown along exponential lines. 
So, today, the unit cost is around a mil¬ 
lion dollars.” 

The capital cost of the equipment to 
produce 1,000 wafers per week has been 
following a similar curve and is now up 
to $55 million. Complexity has gone 
from a 5-mask process to a 20-mask 
process. 


“Clearly, the industry has become 
very capital-intensive,” he declared. “It 
is not unusual for companies to 
spend 25 percent or more of their 
revenues on capital equipment, mainly 
driven by moving to new technologies.” 

It is this kind of reasons that has led 
to the essential disappearance of the 
DRAM business in the United States, he 
said. People look at the investment that 
has to be made to be competitive there 
and find that the likelihood of making a 
return on the investment is sufficiently 
discomfitting that they decide there are 
better ways to invest. 

The proceedings, order No. 1909, is 
available from the Computer Society 
Press, Los Alamitos, California, by 
calling (800) CS-BOOKS or (714) 
821-8380 in California. 


Toward the interactive mathematical notebook 


“In the last couple of years, the 
advances in technology have made it 
feasible to do serious mathematics 
on personal computers,” Stephen 
Wolfram informed the Compcon 
Spring 89 plenary audience March 2. 
He is a professor of physics, 
mathematics, and computer science 
and founder of the Center for Com¬ 
plex Systems Research at the Univer¬ 
sity of Illinois, as well as president of 
Wolfram Research. 

Using a Macintosh II hooked up to 
project its display onto a movie-size 
screen, Wolfram demonstrated what 
could be done (numerical, symbolic, 
graphical) with his program, called 
Mathematica: 

(1) Numerical—One of Wolfram’s 
basic principles is to produce exact 
results, if mathematically possible. 
The effect is to generate several 
screens worth of digits in demonstra¬ 
tion problems, such as raising 3 to 
the 1,000th power. 

(2) Symbolic—The program 
manipulates algebraic formulas, 
accomplishing such operations as 
factoring or finding roots. 

(3) Graphical—Taking a symbolic 
formulation as input, the program 
graphs the results in two- or three- 
dimensional diagrams, enabling the 
scientist or engineer to visualize the 
meaning of his work. 

Mathematica, written in an object- 
oriented extension of the C language, 
contains about 200,000 lines of code, 
160,000 lines in a kernel that do the 
mathematics and 40,000 lines in the 
front end that interface to the partic¬ 
ular computer it is running on, Wol¬ 
fram said. 

A program of this scope will no 
doubt lead to many changes in the 


way mathematics is done. One is to 
computerize Bessel, hyperbolic, and 
other functions that people are still 
looking up in paper tables, Wolfram 
predicted. 

Another is the interactive mathe¬ 
matical notebook. Users could look 
at the symbolic formulas or the 
graphic representations and then go 
behind the surface of the book to do 
some manipulations of their own, 
Wolfram pointed out. In this way they 
could round out their understanding 
of the author’s intent. 

“Just as we expect students to 
have calculators now, it won’t be long 
until we expect them to have tools 
like this,” Wolfram noted. “College 
courses can then deal with the 


higher levels of understanding, leav¬ 
ing it to the program to handle the 
details of computation or manipu- 



Stephen Wolfram made a Compcon 
plenary presentation March 2. 


Neural-style 
computation 
seeks meaning 

“The brain doesn’t understand 
what the brain is doing,” cryptically 
announced Carver A. Mead, profes¬ 
sor of computer science at the 
California Institute of Technology, 
when he spoke March 2 at a Comp¬ 
con Spring 89 plenary session. “The 
only thing we can introspect 
about—that we can see ourselves 
doing—is the cognitive level of pro¬ 
cessing.” 

What the brain is mostly doing, as 
illustrated in Figure 2, is processing 
vast quantities of sensory inputs and 
motor outputs—all below the level of 
awareness. Occasionally, it sorts out 
an exception to the mostly routine 
environment—a tiger suddenly leaps 
out of the brush—and tosses it 
upstairs for the cognitive process to 
work on. 

If we are going to understand how 
the brain works, if we are going to 
use some of its mechanisms in our 
own artifacts, we will have to study it 
from the outside, he said. 

Getting down to fundamentals. “A 

good digital signal processing chip 
in today’s technology will do about 
10 7 operations per second, take 
about 1 watt of power, and cost us 
about 1CT 7 joule per operation," 

Mead noted. “At the system level that 
number increases to about 10" 5 joule 
per operation.” 

In contrast, the brain does about 
10 16 operations per second, and that 
may be too conservative by one or 
two orders of magnitude. It takes a 
few watts. “So the brain is doing 
computations at a cost of something 
like 10' 16 joule per operation,” he 
said. 

If we push out fabrication technol¬ 
ogy to the best we can do with stan¬ 
dard silicon technology, we could get 
10“ 9 joule per operation at the chip 
level, or 1CT 7 joule per operation at 
the system level. “If we were to try to 
do a brain that way, it would take 
about 10 megawatts,” Mead esti¬ 
mated. “That is a bit much to carry 
around on your back. So my conclu¬ 
sion is that we have something to 
learn from the brain.” 

The transistor itself is not using 
much more energy than the computa¬ 
tion elements in the brain. A typical 
transistor uses about 10~ 13 joule to 
charge its gate. “As we evolve the fab 
technology down to submicron 
dimensions, we are going to get that 
number down to about 10~ 15 joule,” 
Mead figured. “So the raw technol¬ 
ogy itself is within one or two orders 
of magnitude of the technology the 
brain uses.” 
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That leaves a difference of 10 6 
between the operation of a single 
transistor and what it takes to 
accomplish an operation at the chip 
level. “To do an operation in digital 
technology, we have to switch some 
10 4 transistors,” he pointed out. “The 
other two orders of magnitude go 
into our old friend, the wire.” 

The brain has a massive amount of 
wiring, too. “There is actually more 
area in the brain dedicated to wires 
than to synaptic elements,” Mead 
reported. “But the actual energy 
spent in driving those wires is about 
the same as the energy spent in the 
synaptic computations.” 

“The lesson I learned is that we do 
a sloppy job of keeping information 
local in the digital systems we build 
now,” he went on. “When we have 
done a better job—in systolic arrays 
or self-timed systems—we will have 
done better in energy terms.” 

Clocked systems use a lot of wire to 
distribute the clocks throughout the 
system. 

“The problem is that we don’t know 
what to do about it,” he said. “Some 
very small examples: we don’t have 
good local architectures; we don’t 
have computation paradigms that 
keep the data relevant to the compu¬ 
tation physically localized on the 
chip.” 

The nervous system does keep 
computation localized. It also lets 
time be its own representation. 
“Signal-processing computation 
uses that kind of representation,” 
Mead commented. “That is one of 
the reasons some very effective 
things have been done there.” 



Carver Mead of Caltech delivered 
the final plenary talk at Compcon 
March 2. 


Adaptation. At first, Mead 
assumed there was some kind of 
similarity between analog computers 
and the brain. In analog computers, 
however, as the signal goes through 
more and more stages, it gets lost in 
the accumulating noise. He thought 
the brain probably overcame this sig¬ 
nal degradation by averaging large 
numbers of signals. 

That turned out to be wrong, he 
learned from work done on the fly. 
Experiments revealed that a fly made 
decisions on which way to fly from 
as few as one or two pulses into a 
neuron. “It simply is not true that the 
nervous system uses the law of large 
numbers to overcome the disadvan¬ 
tages of analog computation,” he 
said. Rather, adaptation is the ner¬ 
vous system’s substitute for pre¬ 
cision. 

Mead calls the adaptive process 
that seems to be working in the lower 
levels of the brain “dumb adapta¬ 
tion.” Data is always coming in from 
the senses in vast quantities and 
there is no disk to store it to. The suc¬ 
cessful organism learned to sort out 
the important stuff fast and throw 
away the rest. 

“Every node in the nervous system 
has got to do that, or you would just 
be washed over by all the garbage,” 
he noted. “Data isn’t precious to the 
nervous system; meaning is.” 

At the lower levels, meaning 
seems to be a deviation from unifor¬ 
mity. The retina expects the visual 
scene to be uniform in intensity. 
Where it is not, that is meaningful. 
The first-level neurons report that 
interesting fact to the next level. And 
so on up through many levels, each 
one apparently sorting out some¬ 
thing else of interest. That is dumb 
adaptation. 


This process of identifying a sin¬ 
gle meaningful characteristic, such 
as light intensity, is fairly simple, in 
fact, it can be replicated in a resistive 
network. Mead showed a videotape 
of his two-level light-sensitive resis¬ 
tive network in operation. 

His resistive-network chip does 
something on the order of 10 s opera¬ 
tions per second, has 10 5 devices, 
draws 1 milliwatt, and takes about 
1CT 11 joule per operation. This num¬ 
ber is not as good as the nervous 
system, 10“ 16 , but it is considerably 
better than present digital systems, 
1CT 7 . 

“Moreover, the resistive-network 
style of computation is inherently 
tolerant of defects,” Mead pointed 
out. “If something goes wrong, every¬ 
thing else adapts to the blind spot. 
After a couple of levels, you don’t see 
it any more.” 

That makes the use of wafer-scale 
integration feasible. Today, a wafer 
can carry about 10 8 devices. In 
another decade we will probably 
have increased that density by a cou¬ 
ple of orders of magnitude, Mead 
estimated. “Well, 10 10 is starting to be 
a respectable number even by the 
standards of the nervous system. 
Typically, we run these devices at 
something like a nanoampere per 
device, or about 0.1 watt per wafer. 
That doesn’t pose a big heat- 
dissipation problem.” 

A little beyond that, we can 
imagine putting together a system of 
a thousand wafers. Now we are up to 
10 16 operations per second. 

“It doesn’t mean that we will be 
able to do the same things a human 
being does, but it does mean that we 
will be able to do some awesome 
tasks in the areas of perception and 
motor control,” Mead concluded.” 


-WM 



Figure 2. Most of the brain operates below the level we can reach through intro¬ 
spection. 
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Researchers 
and 

Developers 
Subject: Short Quiz 

How do you make your newly 
developed neural network part 
of your product? 

□ 1) Develop a network with a 
neural network simulator and 
write your own code to interpret 
and execute the results. 


□ 2) Start from scratch using a 
“Neural Network Language” and 
write your own development en¬ 
vironment. 

□ 3) Roll your own network and 
development environment from 
scratch. 


NeuralWorks 
Professional II with 
Designer Pack ..... 

The logical alternative 

Together with NeuralWorks 
Professional II, Designer Pack is 
the most elegant method for de¬ 
signing, testing and deploying 
neural networks. The develop¬ 
ment blends naturally with appli¬ 
cation production. There is no 
need to learn special “Neural Net¬ 
work Programming Languages” 
which may be restricted to one or 
two special hardware systems. 
Build a network in a way that 
makes sense: graphically. Proto¬ 
type your interfaces with User 
I/O. Turn it all into useable appli¬ 
cation code with Designer Pack. 
Nothing wasted. No re-design. No 
re-learning. Simple. Elegant. 
Seamless. 

The sensible approach 
to neural network 
development 

NeuralWorks Professional II 
and NeuralWorks Designer Pack 
are available on the Sun 3,4,386i, 
N-Cube, Macintosh, PC AT, XT, 
PS2 and compatible machines. 

Call TODAY or write for infor¬ 
mation about NeuralWare’s 
software, seminars, and custom 
engineering services. Ask for 
Jane Klimasauskas, Vice- 
President Sales and Marketing. 


Authorized Distributors: 

Electronic Associates GmbH 
FranzstraBe 107 
D-5100 Aachen 
West Germany 

Telephone: 011-49(241)26041/42 

Scientific Computers Limited 

50 Victoria Road 

Burgess Hill 

West Sussex RH15 9LW 

England 

Telephone: 011-44(444)65101 
NovaCast Expert Systems 
Soft Center 

S-37200 Ronneby, Sweden 
Telephone: 011-46(457)718-30 
Informagic, S.A. 

Avgda, de Roma, 152 
Barcelona 08011 
Spain 

Telephone: 011-34(3)254-6235 
Electronic Associates Sari 
25-27 Rue Ginoux 
75737 Paris Cedex 15 
France 

Telephone: 011-33(1)45770813 
Nichimen Data System Corp. 
Kyodo Building 

3-2, 1-Chome Nihonbashi-honcho 
Chuo-ku, Tokyo 103, Japan 
Telephone: 011-81(3)241-2611 


NeuralWare 

I NCO R PORATED 
103 Buckskin Court 
Sewickley, PA 15143 
(412) 741-5959 

Reader Service Number 7 


□ 4) None of the above! 

The answer is “4” - none of the 
above. NeuralWorks Professional 
II in conjunction with Designer 
Pack makes all other methods of 
neural development obsolete. The 
development environment 
(NeuralWorks Professional II) is 
seamlessly integrated with the 
deployment environment 
(NeuralWorks Designer Pack). It 
is easy to move back and forth 
between the two of them. You can 
try out as many networks and 
variations as you want. And when 
you’re ready, you have a “C” pro¬ 
gram with a well-defined inter¬ 
face which will run identically to 
the network you proto-typed! 












Langeler to address evolution of electronic design during DAC 89 keynote 


“Electronic Design Automation 
Comes of Age” will be the keynote 
theme when Gerard Langeler, founder, 
president, and chief operating officer of 
Mentor Graphics, addresses the 1989 
Design Automation Conference. The 
event is set June 25-29 at the Las Vegas 
Convention Center. 

Donald Thomas of Carnegie Mellon 
University is general chair of the 26th 
DAC, and A. Richard Newton of the 
University of California at Berkeley is 
serving as program chair. The event is 
sponsored by the IEEE Computer Soci¬ 
ety Design Automation Technical Com¬ 
mittee and the Association for 
Computing Machinery Special Interest 
Group on Design Automation. 

Langeler’s talk will review some les¬ 
sons leai ned from the evolution of elec¬ 
tronic d< sign automation over the past 
10 years and survey how the next 
decade \ ill represent a marked contrast 
to what las transpired before. Today, 
through parallel advances in electronic 
design a rtomation and ASIC technol¬ 
ogy, enj ineers routinely produce chips 
that fur :tion correctly at first silicon. 

Some observations Langeler will 
make regarding the past decade pertain 
to the fact that acceptance of the new 
technologies among the design commu¬ 
nity has been slow; that new technolo¬ 
gies are absorbed much more rapidly 


than new methodologies; that the ques¬ 
tion of whether electronic design auto¬ 
mation (EDA) really “worked” has 
turned out to be a question of confi¬ 
dence rather than capabilities; and that, 
while EDA may act as a gateway to new 
methodologies, it cannot do so at the 
expense of existing ones, as was the case 
with silicon compilers. 

The keynoter will discuss several cur¬ 
rent trends that will continue into the 
next decade. One example is the 
decreased flow of EDA technology 
from academia to industry because 
most product development is now done 
in the private sector. Over the next 10 
years, the focus of EDA will shift from 
chip design to systems design; EDA sys¬ 
tems will be much more open with 
broad frameworks that allow diverse 
EDA tools to coexist in the same envi¬ 
ronment; and EDA will continue to 
exploit the vast increase in computer 
power that promises to occur in the 
coming decade. 

Langeler will highlight lessons to be 
learned from the past decade in EDA: 

• engineering departments must 
adopt EDA or risk a fatal competitive 
handicap if they don’t—the faster you 
can absorb the technology, the greater 
the competitive advantage; 

• in-house EDA developers must take 
care to ensure that their work doesn’t 


duplicate ongoing proliferation of EDA 
tools in the commercial market; and 

• universities must take the high 
ground by providing the theoretical 
framework in which new tools can be 
developed. 

DAC 89 will feature 45 technical ses¬ 
sions covering such major areas as logic 
level and higher levels of synthesis and 
design optimization, timing verifica¬ 
tion, high-level specification and design 
languages, neural networks for elec¬ 
tronic design automation, and the social 
and ethical impact of the microelec¬ 
tronics industry on our society. 

In addition, six full-day tutorial ses¬ 
sions will be held June 29, entitled “An 
Introduction to VHDL,” “Computer- 
Aided Software Engineering for 
Engineering Software Development,” 
“Using EDIF to Describe Electronic 
Design Data,” “Introduction to Testing 
for VLSI Designers,” “Logic and 
Behavioral Design Synthesis,” and 
“Timing Verification.” Since atten¬ 
dance will be limited, early registration 
is recommended. 

Registration information for the con¬ 
ference and tutorials is available by con¬ 
tacting the Design Automation 
Conference Registration Desk, 7490 
Clubhouse Road, Suite 102, Boulder, 
CO 80301, phone (303) 530-4333. 


FTCS 19 to feature session on fault tolerant 
computing from industrial perspective 


Kewal Saluja, University of Wisconsin 

“Industrial Perspective on Fault 
Tolerant Computing” will be the sub¬ 
ject of a first-ever special session at the 
19th International Symposium on Fault 
Tolerant Computing June 21-23. FTCS 
19 will be held at the Hyatt Regency in 
Chicago. 

The special session, strictly composed 
of invited presentations from the inter¬ 
national industrial community, will 
include case studies of commercial fault 
tolerant systems as well as systems that 
are in research and development stages 
today but are likely to be the commer¬ 
cial systems of tomorrow. 

Ravi Iyer of the University of Illinois 
and Jacob Abraham of the University 
of Texas at Austin are serving as 
general co-chairs of FTCS 19, with 
S.M. Reddy of the University of Iowa 
the program chair. The symposium is 
sponsored by the IEEE Computer Soci¬ 
ety, the society’s Technical Committee 


on Fault Tolerant Computing, the Uni¬ 
versity of Illinois at Urbana- 
Champaign, and the International Fed¬ 
eration for Information Processing. 

The conference will be devoted to 
state-of-the-art issues in fault tolerant 
computing and will encompass all 
aspects of specifying, designing, model¬ 
ing, implementing, testing, diagnosing, 
and evaluating dependable and fault 
tolerant computing systems and their 
components. 

As such, the scope of the conference 
will not be limited to any one method of 
fault tolerance but will include both 
hardware and software fault tolerant 
techniques. 

FTCS will feature 2'/ : days of techni¬ 
cal presentations in three parallel ses¬ 
sions, with papers reflecting both a 
theoretical nature and a practical sig¬ 
nificance. 

The theory papers have not only been 
chosen to provide a foundation for the 
work being performed in this area but 


also to serve as a guide to the future of 
reliable computing. Typically, the prac¬ 
tical papers will present state-of-the-art 
implementations of the fault tolerant 
systems. 

In addition, two panel discussions, 
“Computer-Aided Design of Mission- 
Critical Architectures” and “Expert 
Systems for Diagnosis,” are planned. 

Other conference events will include a 
technical tour of AT&T Bell Laborato¬ 
ries and a workshop on “Hardware 
Fault Tolerance in Multiprocessor Sys¬ 
tems” at the Urbana-Champaign 
campus. 

For more information about the con¬ 
ference and/or the workshop, contact 
Kewal Saluja, Electrical and Computer 
Engineering, University of Wisconsin, 
Madison, WI 53706, phone (608) 
262-6490; or Prith Banerjee, Coordi¬ 
nated Science Laboratory, University of 
Illinois, Urbana, IL 61801, phone (217) 
333-6564. 
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ICDCS panelists focus 
on distributed virtual 
memory, design tools 


CALL FOR PAPERS 


Dharma P. Agrawal 

North Carolina State University 

Panel discussions on “Distributed 
Virtual Memory” and “Practicality of 
Distributed System Design Tools” will 
be conducted as part of the ninth Inter¬ 
national Conference on Distributed 
Computing Systems June 5-9. ICDCS 
will be held at the Marriott Hotel in 
Newport Beach, California. 

The conference is sponsored by the 
IEEE Computer Society’s Technical 
Committee on Distributed Processing. 
Kane Kim of the University of Califor¬ 
nia at Irvine is the general chair, and 
Norman Schneidewind of the Naval 
Postgraduate School is the program 
chair. 

Richard LeBlanc of the Georgia Insti¬ 
tute of Technology will chair the “Dis¬ 
tributed Virtual Memory” panel, and 
Horst F. Wedde of Wayne State Uni¬ 
versity will chair the “Practicality of 
Distributed System Design Tools” 
session. 

Twenty-three technical paper sessions 
are planned in such subject areas as 
concurrency control, distributed 
algorithms, distributed architectures, 
distributed languages, load sharing, 
reliability models, system performance, 
and transaction management. 

Four tutorials will be held to provide 
in-depth information on important 
aspects of distributed computing. Two 
are scheduled Monday, June 5, entitled 
“Fault-Tolerant Distributed Systems” 
by Flavio Chirstian of the IBM 
Almaden Research Laboratory and 
“Concurrency and Coherency Control 
for Multisystem Transaction Process¬ 
ing” by Alex Thomasion and E. Rahm 
of the IBM T.J. Watson Research Cen¬ 
ter. The other tutorials, “Parallel Pro¬ 
cessing Networks and Systems” by 
Howard J. Siegel of Purdue University 
and “Distributed Database Manage¬ 
ment Systems” by S. Rahimi of 
Infospan and the University of Min¬ 
nesota, are set for Friday, June 9. 

Complete registration information, 
including program details, can be 
obtained by contacting the IEEE Com¬ 
puter Society, phone (202) 371-0101; 
the publicity co-chairs, Waiter A. Burk- 
hard, University of California, La 
Jolla, phone (619) 534-2722, and 
Dharma P. Agrawal, North Carolina 
State University, phone (919) 737-3984; 
or by consulting the ad on pp. 74-75 of 
the April 1989 issue of Computer. 


IEEE Micro seeks articles for general- 
interest issues in 1989 and 1990. Sug¬ 
gested topics include neural networks, artifi¬ 
cial intelligence, special-purpose computers, 
optical computers and interfaces, worksta¬ 
tions, use of microprocessors in parallel 
computers, VHDL design, silicon compila¬ 
tion, and biological computing. Tutorials are 
welcome on all micro-related topics. Submit 
manuscripts to Joe Hootman, Editor-in- 
Chief, EE Dept., Univ. of North Dakota, PO 
Box 7165, Grand Forks, ND 58202, phone 
(701) 777-4331. 

CHI 90, Human Factors in Computing Sys¬ 
tems 1990: Apr. 1-5, 1990, Seattle. Sponsor: 
ACM. To obtain the call for participation 
form, contact Toni MacHaffie, PO Box 5847, 
Beaverton, OR 97006, phone (503) 591 - 
1981. 


OT11 Fifth Aerospace Computer Security 
Applications Conf.: Dec. 4-8, 1989, 
Tucson, Ariz. Submit paper by May 19, 
1989, to Ronald A. Gove, Booz-Allen and 
Hamilton, 4330 East-West Hwy., Bethesda, 
MD 20814, phone (301) 951-2395. Submit 
tutorial proposal to Dixie B. Baker, The 
Aerospace Corp., PO Box 92957, Los Ange¬ 
les, CA. 

Fifth Int’l Congress on Advances in Non¬ 
impact Printing Technologies: Nov. 12-17, 
1989, San Diego, Calif. Sponsor: Society for 
Imaging Science and Technology. Submit 
abstract by May 22, 1989, to John Moore, 
Tektronix, PO Box 500, MS 50-321, Beaver¬ 
ton, OR 97077, phone (503) 627-5067. 

IEEE Network: January 1990. A special is¬ 
sue is planned on provisioning for the future 
network. Submit abstract as soon as possible 
and manuscript by May 30, 1990, to Manu 
Malek, AT&T Bell Labs, Rm. 2C-218, 480 
Red Hill Rd„ Middletown, NJ 07748, phone 
(201) 615-4480. 


1989 IEEE Ultrasonics Symp.: Oct. 3-6, 
1989, Montreal. Sponsor: IEEE Ultrasonics, 
Ferroelectrics, and Frequency Control Soci¬ 
ety. Submit abstract by May 31, 1989, to 
Gary K. Montress, c/o LRW Associates, 

1218 Balfour Dr., Arnold, MD 21012, phone 
(617) 860-3053. 


Prociem 89, Second Conf. on Productivity 
through Computer Integrated Engineering 
and Manufacturing: Nov. 13-15, 1989, 
Orlando, Fla. Sponsor: Florida High Tech¬ 
nology and Industry Council. Submit ab¬ 
stract by May 31, 1989, to Stanley Y.W. Su, 
Database Systems R&D Center, Univ. of 
Florida, Gainesville, FL 32611, phone (904) 
335-8458; or Terry E. Shoup, Office of Aca¬ 
demic Affairs, Florida Atlantic Univ., Boca 
Raton, FL 33431, phone (407) 338-2267. 


Compcon Spring 90: Feb. 26-Mar. 2, 
1990, San Francisco. Submit paper by 
June 1, 1989, to Kenichi Miura, Computa¬ 
tional Research Dept., MS B2-7, Fujitsu 
America, 3055 Orchard Dr„ San Jose, CA 
95134-2017, phone (408) 432-1300, ext. 
5408 or 5723. 


Fourth SIAM Conf. on Parallel Processing 
for Scientific Computing: Dec. 11-13, 

1989, Chicago. Sponsor: Society for Indus¬ 
trial and Applied Mathematics. Submit ab¬ 
stract by June 1, 1989, to SIAM Conf. Coor¬ 
dinator, 117 S. 17th St., 14th Floor, Philadel¬ 
phia, PA 19103-5052, phone (215) 564- 
2929. 


Sixth Israeli Conf. on Artificial Intelli¬ 
gence and Computer Vision: Dec. 26-27, 
1989, Tel Aviv. Sponsor: Information Proc¬ 
essing Assoc, of Israel. Submit paper by 
June 1, 1989, to J. Rosenschein, Computer 
Science Dept., Hebrew Univ., 91904 Jerusa¬ 
lem, Israel (for AI submittals); or Y. Ye- 
shurun. Computer Science Dept., Tel Aviv 
Univ., 69978 Tel Aviv, Israel (for computer 
vision submittals). 


Second Int’l Symp. on Artificial Intelli¬ 
gence: Oct. 23-27, 1989, Monterrey, Mex¬ 
ico. Submit abstract and paper by May 31, 
1989, to Francisco J. Cantu, Inst. Tecno- 
logico de Monterrey, ITESM Sue. Correos 
“J", Monterrey, N.L., Mexico 64849, phone 
52 (83) 58-20-00. 


23rd Asilomar Conf. on Signals, Sys¬ 
tems, and Computers: Oct. 30-Nov. 1, 
1989, Pacific Grove, Calif. Cosponsors: Na¬ 
val Postgraduate School, San Jose State 
Univ. Submit abstract and summary by June 
1, 1989, to George M. Dillard, Code 7402, 
Naval Ocean Systems Center, San Diego, CA 
92152-5000, phone (619) 553-2478. 


jl Third Int’l Software for Strategic 
" Systems Conf.: Feb. 27-28, 1990, 
Huntsville, Ala. Cosponsors: IEEE Computer 
Society Huntsville Chapter, Univ. of Ala¬ 
bama in Huntsville. Submit paper by May 
31, 1989, to Univ. of Alabama in Huntsville, 
Continuing Education Div., Tom Bevill Cen- 
r 285, Huntsville, AL 35899, phone (800) 
448-4035 or (205) 895-6372. 


Eurasip Workshop on Neural Networks: 

Feb. 15-17, 1990, Sesimbra, Portugal. Co¬ 
sponsors: European Assoc, for Signal Proc¬ 
essing, IEEE, Instituto de Engenharia de Sis- 
temas e Computadores. Submit summary by 
June 1, 1989, to Christian Wellekens, Phil¬ 
ips Research Lab, Av. Van Becelaere 2, Box 
8, B-1170 Brussels, Belgium, phone 32 (2) 
674-2275. 
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HICSS 23, 23rd Hawaii Int’l Conf. 
on System Sciences: Jan. 3-6, 1990, 
Kona, Hawaii. Cosponsor: ACM. Submit pa¬ 
per by June 5, 1989, to Luqi, Computer Sci¬ 
ence Dept., Naval Postgraduate School, 
Monterey, CA 93943, phone (408) 646- 
2735. 

Sixth Int’l Conf. on Data Engineer- 
ing: Feb. 5-9, 1990, Los Angeles. Sub¬ 
mit paper by June 15, 1989, to Ming T. Liu, 
Computer and Information Science Dept., 
Ohio State Univ., 2036 Neil Ave., Columbus, 
OH 43210-1277, phone (614) 292-1837. 

((fjl IEEE Int’l Workshop on Tools for 
Artificial Intelligence: Oct. 23-25, 
1989, Fairfax, Va. Submit paper or summary 
by June 15, 1989, to Nikolas G. Bourbakis, 
Electrical and Computer Engineering Dept., 
Machine Vision Research Lab, George Ma¬ 
son Univ., 4400 University Dr., Fairfax, VA 
22030, phone (703) 425-3930. 

IEEE Workshop on Interpretation of 

3D Scenes: Nov. 27-29, 1989, Austin, 
Texas. Submit paper by June 15, 1989, to 
Eric Crimson, Artificial Intelligence Lab., 
MIT, 545 Technology Square, Cambridge, 
MA 02139. 

Fourth Int’l Workshop on High- 
Level Synthesis: Oct. 15-18, 1989, 
Kennebunkport, Maine. Cosponsor: ACM. 
Submit extended abstract by June 16, 1989, 
to Raul Camposano, IBM Research Div„ T.J. 
Watson Research Center, PO Box 218, York- 
town Heights, NY 10598, phone (914) 945- 
3971. 

AIDA 89, Fifth Conf. on Artificial Intelli¬ 
gence and Ada: Nov. 16-17, 1989, Fairfax, 
Va. Cosponsors: George Mason Univ., Inst, 
for Defense Analyses, Software Productivity 
Consortium. Submit paper by June 30, 1989, 
to AIDA 89, Computer Science Dept., 

George Mason Univ., 4400 University Dr., 
Fairfax, VA 22030, phone (703) 323-2713. 

HCI Int’l 89, Third Int’l Conf. on Human- 
Computer Interaction: Sept. 18-22, 1989, 
Boston. Cosponsors: Assoc, of American 
Publishers et al. Submit abstract by June 30, 
1989, to Gavriel Salvendy, 263 Grissom 
Hall, Purdue Univ., West Lafayette, IN 
47907, phone (317) 494-5426. 

IEEE Trans. Computers: April 1990. 

A special issue is planned on fault-tol¬ 
erant computing. Submit manuscript by July 
1, 1990, to S.M. Reddy, Electrical and Com¬ 
puter Engineering Dept., Univ. of Iowa, 

Iowa City, IA 52242, phone (319) 335-5191. 

IFIP Int’l Workshop on Applied Formal 
Methods for Correct VLSI Design: Nov. 
13-16, 1989, Leuven, Belgium. Cosponsors: 
IFIP, Interuniversity Micro Electronics Cen¬ 
ter. Submit paper by July 1, 1989, to Luc 
Claesen, IMEC vzx, Kapeldreef 75, B-3030 
Leuven, Belgium, phone 32 (16) 281-203. 

ICSE 12, 12th Int’l Conf. on Soft- 
ware Engineering: Mar. 26-30, 1990, 
Nice, France. Cosponsors: ACM et al. Sub¬ 


mit paper by July 14, 1989, to Peter Free¬ 
man, ICSE 12 Program, ICS Dept., Univ. of 
California at Irvine, Irvine, CA 92717, phone 
(714) 856-7403; or Marie-Claude Gaudel, 
ICSE 12 Program, AFCET, 156 Bd. Pereire, 
75017 Paris, France. 

^ IPCCC, Ninth IEEE Int’l Phoenix 
Conf. on Computers and Communi¬ 
cations: Mar. 21-23, 1990, Scottsdale, Ariz. 
Submit abstract and paper by July 14, 1989, 
to Ralph Martinez, Electrical and Computer 
Engineering, Univ. of Arizona, Tucson, AZ 
85721, phone (602) 621-6174. 

First Int’l Conf. on Systems Integra- 
tion: Apr. 23-26, 1990, Morristown, 
N.J. Cosponsors: New Jersey Inst, of Tech¬ 
nology et al. Submit paper by July 25, 1989, 
to Peter A. Ng, Computer and Information 
Science Dept., New Jersey Inst, of Technol¬ 
ogy, Newark, NJ 07102, phone (201) 596- 
3387. 

First Conf. on Visualization in Biomedical 
Computing: May 22-25, 1990, Atlanta. 
Sponsors: National Science Foundation et al. 
Submit abstract by July 31, 1989, to 
Norberto Ezquerra, Office of Interdiscipli¬ 
nary Programs, Georgia Tech, Atlanta, GA 
30332, phone (404) 894-3964. 

Parbase 90, Int’l Conf. on Databases, 
’nS?’ Parallel Architectures, and their Ap¬ 
plications: March 6-9, 1990, Miami Beach. 
Cosponsors: Florida International Univ. et al. 
Submit paper by Aug. 4, 1989, to Parbase 
90, School of Computer Science, Florida In¬ 
ternational Univ., Miami, FL 33199, phone 
(305) 554-3429 or 3386. 

CompEuro 90, IEEE Int’l Conf. on 
Computer Systems and Software En¬ 
gineering: May 7-9, 1990, Tel Aviv. Co¬ 
sponsors: IEEE, Information Processing As¬ 
soc. of Israel. Submit abstract by Sept. 1, 
1989, to CompEuro 90 Conference Secretar¬ 
iat, c/o ORTRA, POB 50432, Tel Aviv, 

61500, Israel, phone 972 (3) 664-825. 

EDAC 90, European Design Automa- 
tion Conf.: Mar. 12-15, 1990, Glas¬ 
gow, Scotland. Submit abstract/paper by 
Sept. 4, 1989, to EDAC 90 Secretariat, CEP 
Consultants, 26-28 Albany St., Edinburgh, 
EH1 3QH, UK, phone 44 (31) 557-2478. 

CTM Second Int’l Symp. on Databases in 
Parallel and Distributed Systems: 

July 2-4, 1990, Dublin, Ireland. Cosponsor: 
ACM. Submit paper by Oct. 16, 1989, to 
Rakesh Agrawal, AT&T Bell Labs, Rm. 
3D450, 600 Mountain Ave., Murray Hill, NJ 
07974, phone (201) 582-2250; or David 
Bell, Inst, of Informatics, Univ. of Ulster, 
Jordanstown, County Antrim, Northern Ire¬ 
land BT370QB, phone (0232) 365-131. 

COIS 90, Conf. on Office Informa- 
tion Systems: Apr. 25-27, 1990, Cam¬ 
bridge, Mass. Cosponsor: ACM. Submit pa¬ 
per by Nov. 3, 1989, to Fred Lochovsky, 
Computer Science Dept., 10 King’s College 
Circle, Univ. of Toronto, Toronto, Ont. M5S 
1A4, Canada, phone (416) 978-7441. 
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wfv Eifth Int’l Workshop on Software 
Specification and Design, May 19-20, 

Pittsburgh. Cosponsor: ACM. Contact Sol J. 
Greehspan, GTE Labs, 40 Sylvan Rd., 
Waltham, MA 02254, phone (617) 466- 
2962; or Colin Potts, MCC, 9390 Research 
Blvd., Kaleido II Bldg., Austin, TX 78759, 
phone (512) 338-3629. 

jffjj First IEEE Symp. on Parallel and 
Distributed Processing, May 22-23, 

Dallas. Sponsor: Dallas Section of the IEEE 
Computer Society. Contact Mark Shad- 
owens, Information Technologies Lab, Texas 
Instruments, PO Box 655474, MS 238, Dal¬ 
las, TX 75265, or call Behrooz Shirazi at 
(214) 692-2874. 

AMAST, Int’l Conf. on Algebraic Method¬ 
ology and Software Technology, May 22- 
24, Iowa City, Iowa. Contact Eugene Madi¬ 
son or Teodor Rus, Computer Science and 
Mathematics Dept., Univ. of Iowa, Iowa 
City, IA 52242, phone (319) 335-0742 or 
0694. 

Sixth Int’l Conf. on Testing Computer 
Software, May 22-25, Washington, DC. 
Sponsors: DPMA, ACM. Contact Genevieve 
Houstort-Ludlam, Frontier Technologies, 
2444 Solomons Island Rd., Suite 205, Anna¬ 
polis, MD 21401, phone (301) 266-8244. 

10th Tunisian French Seminar of 
Computer Science: The Role of Lan¬ 
guages in Programming, May 23-25, Tunis, 
Tunisia. Cosponsor: Tunisian Information 
Processing Society. Contact Abdelfettah 
Belghith, Dept. d’Informatique, Faculte des 
Sciences de Tunis, 1002 Belvedere Tunisa; 
or Ali Mili, Faculty of Sciences, Univ. of 
Tunis II, Campus Universitaire, 1002 Belve¬ 
dere, Tunisia. 

SIGMetrics 89 and Performance 89, May 
23-26, Berkeley, Calif. Sponsors: ACM, 

IFIP. Contact Luis-Felipe Cabrera, IBM Al- 
maden Research Center, Mail Code K52/803, 
San Jose, CA 95120-6099, phone (408) 927- 
1838. 

ICCI 89, Int’l Conf. on Computing and In¬ 
formation, May 23-27, Toronto. Contact 
Waldemar W. Koczkodaj, Laurentian Univ., 
CoSc, Sudbury, Ont., Canada P3E 2C6, 
phone (705) 675-1151. 

Workshop on New Directions in Computer 
Chess, May 28-June 1, Edmonton, Alta., 
Canada. Sponsors: Int’l Computer Chess As- 
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fore the month of publication (i.e., for the July 1989 issue, send information 
for receipt by May 15, 1989) to Chuck Governale, Calendar Dept., Computer, 
10662 Los Vaqueros Circle, Los Alamitos, CA 90720. 


soc., Canadian Information Processing Soci¬ 
ety. Contact Tony Marsland, Computing Sci¬ 
ence Dept., Univ. of Alberta, Edmonton, 
Alta., Canada T6G 2H1. 


/ftjl 16th Int’l Symp. on Computer Archi- 
v|y tecture, May 28-June 1, Jerusalem, 
Israel. Cosponsor: ACM. Contact M. Yoeli, 
Computer Science Dept., Technion City, 
Haifa 32000, Israel, phone 972 (4) 294-314. 


ftj) 19th Int’l Symp. on Multiple-Valued 

^Ay Logic, May 29-31, Guangzhou, China. 
Cosponsors: Chongging Univ. et al. Contact 
David M. Miller, Computer Science Dept., 
Univ. of Victoria, B.C., Canada, V8W 2Y2, 
phone (604) 721-7220. 


Congress 89, May 29-June 2, Edmonton, 
Alta., Canada. Sponsor: Canadian Informa¬ 
tion Processing Society. Contact Congress 
89, PO Box 1277, Main Post Office, Edmon¬ 
ton, Alta., Canada T5J 2M8, phone (403) 
488-1879. 


jWft; Int’l Conf. on Systolic Arrays, May 
^47 31-June 2, Killamey, Ireland. Cospon¬ 
sor: Queen’s Univ. of Belfast. Contact Earl 
Swartzlander, TRW, 1 Space Park, Redondo 
Beach, CA 90278, phone (213) 535-4321. 


June 1989 


IEEE Pacific Rim Conf. on Communica¬ 
tions, Computers, and Signal Processing, 
June 1-2, Victoria, B.C., Canada. Sponsor: 
IEEE Victoria Section, Univ. of Victoria. 
Contact Warren D. Little, Dept, of Electrical 
and Computer Engineering, Univ. of Victo¬ 
ria, PO Box 1700, Victoria, B.C., Canada 
V8W 2Y2, phone (604) 721-8686. 

ICGA 89, Third Int’l Conf. on Genetic Al¬ 
gorithms, June 4-7, Washington, DC. Con- 


CVPR 89, Conf. on Computer Vision 
vAy and Pattern Recognition, June 4-8, 

San Diego, Calif. Contact Rama Chellappa, 
PHE324, Electrical Engineering-Systems 
Dept., Univ. of Southern California, Univer¬ 
sity Park, MC-0272, CA 90089, phone (213) 
743-8559. 

Fourth Israel Conf. on Computer 
v*y Systems and Software Engineering, 
June 5-6, Tel Aviv. Cosponsors: Israel 
Chapter of IEEE Computer Society, Informa¬ 
tion Processing Assoc, of Israel. Contact S. 
Koenig, Ortra Ltd., PO Box 50432, Tel Aviv 
61500, Israel, phone 972 (3) 664-825. 

Fourth Symp. on Logic in Computer 
vly Science, June 5-8, Pacific Grove, 

Calif. Cosponsor: ACM. Contact Albert 
Meyer, Computer Science Lab, MIT, 545 
Technology Square, Cambridge, MA 02139. 

Ninth Int’l Conf. on Distributed 
vA/ Computing Systems, June 5-9, New¬ 
port Beach, Calif. Contact Kane Kim, Com¬ 
puter Engineering Program, Electrical Engi¬ 
neering Dept., Univ. of California at Irvine, 
Irvine, CA 92717, phone (714) 856-5542. 

|ft^| Working Conf. on Computer-Aided 
N§y Design Systems Using Artificial Intel¬ 
ligence Techniques, June 6-7, Tokyo. Co¬ 
sponsors: IFIP, IPSJ. Contact Akihiko 
Yamada, NEC, 4-14-22 ShibaUra, Minato-ku, 
Tokyo 108, Japan; or Kozo Kinoshita, Fac¬ 
ulty of Integrated Arts and Sciences, Hiro¬ 
shima Univ., 1-1-89 Sendamachi, Naka-ku, 
Hiroshima 730, Japan, phone 81 (82) 249- 
9150. 

Third Int’l Workshop on Wafer Scale Inte¬ 
gration, June 6-8, Como, Italy. Sponsor: 
IFIP. Contact Mariagiovanna Sami, Dip. di 
Elettronica, Politecnico di Milano, Piazza 


Leonardo da Vinci 32, 1-20133 Milan, Italy, 
phone 39 (2) 23-99-35-16. 


(ft)) Second Int’l Conf. on Industrial and 
v|y Engineering Applications of Artifi¬ 
cial Intelligence and Expert Systems, June 
6-9, Tullahoma, Tenn. Cosponsors: ACM, 
Univ. of Tennessee Space Inst. Contact 
Moonis Ali, Univ. of Tennessee Space Inst., 
Tullahoma, TN 37388, phone (615) 455- 
0631. 


Ninth Int’l Symp. on Protocol Specifica¬ 
tion, Testing, and Verification, June 6-9, 
Enschede, The Netherlands. Sponsor: IFIP. 
Contact ICSC, Univ. of Twente, PO Box 
217, 7500 AE Enschede, The Netherlands. 


(ftj) Computer Security Foundations II, 
^y June 12-14, Franconia, N.H. Contact 
Jonathan K. Millen, Mitre Corp., MS B321, 
Burlington Rd., Bedford, MA 01730, phone 
(617) 271-3580. 


Eighth Biennial University/Government/ 
Industry Microelectronics Symp., June 12- 

14, Westborough, Mass. Sponsors: Int’l So¬ 
ciety for Hybrid Microelectronics, IEEE. 
Contact Richard B. Gold, Massachusetts Mi¬ 
croelectronics Center, 75 North Dr., West- 
borough, MA 01581. 

Workshop on Automatic Verification 
Methods for Finite State Systems, June 12- 
14, Grenoble, France. Sponsor: C-cUbe, the 
French National Project on Parallelism. Con¬ 
tact Edmund M. Clarke, Jr., Carnegie Mellon 
Univ., Computer Science Dept., Pittsburgh, 
PA 15213-3890; A. Pnueli, Weizmann Inst., 
Rehovot, Israel; or J. Sifakis, LGI-IMAG, BP 
53X, 38041 Grenoble Cedex, France. 

Summer Usenix Technical Conf., June 12- 

16, Baltimore. Sponsor: Usenix Assoc. Con¬ 
tact Usenix Conf. Office, PO Box 385, 

16951 Pacific Coast Hwy, Sunset Bedch, CA 
90742, phone (213) 592-1381. 

ICAIL 89, Second Int’l Conf. on Artificial 
Intelligence and Law, June 13-16, Vancou¬ 
ver, Canada. Contact Robert T. Franson or 
Joseph C. Smith, Faculty of Law, Univ. of 
British Columbia, Vancouver, B.C., Canada, 
phone (604) 228-2323. 

Int’l Conf. on Software Engineering and 
Knowledge Engineering, June 15-17, Chi¬ 
cago. Contact Shi-Kuo Chang, Computer 
Science Dept., Univ. of Pittsburgh, 322 
Alumni Hall, Pittsburgh, PA 15260, phone 
(412) 624-8490. 


First Symp. on Parallel Algorithms and 
Architectures, June 18-21, Santa Fe, N.M. 
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Sponsor: ACM. Contact Tom Leighton, Math 
Dept, and Computer Science Lab, MIT, Cam¬ 
bridge, MA 02139. 

t£ij\ NECC 89, 10th National Educational 
vS' Computing Conf., June 18-22, Bos¬ 
ton. Cosponsor: Int’l Council for Computers 
in Education. Contact Nancy Roberts or Sue 
Friel, Lesley College, 29 Everett St„ Cam¬ 
bridge, MA 02138-1191, phone (617) 868- 
9600; Michael C. Mulder, Applied Research, 
Univ. of Portland, 5000 N. Willamette Blvd., 
Portland, OR 97203, phone (503) 283-7433; 
or NECC 89, ICCE, Univ. of Oregon, 1787 
Agate St., Eugene, OR 97403-9905. 

(3^1 Int’l Workshop on Hardware Fault 
Tolerance in Multiprocessors, June 
19-20, Urbana, Ill. Contact Prith Banerjee, 
Coordinated Science Lab, Univ. of Illinois, 
1101 W. Springfield Ave., Urbana, IL 
61801, phone (217) 333-6564. 

CHDL 89, Ninth Int’l Symp. on Corn¬ 
'S' puter Hardware Description Lan¬ 
guages and Applications, June 19-21, 

Washington, DC. Cosponsors: IFIP, ACM. 
Contact John A. Darringer, IBM T.J. Watson 
Research Center, PO Box 218, Yorktown 
Heights, NY 10598, phone (914) 945-1018. 


Sixth Int’l Workshop on Database Ma¬ 
chines, June 19-21, Deauville, France. 
Sponsors: INRIA, AFCET. Contact Haran 
Boral, MCC, 3500 W. Balcones Center Dr., 
Austin, TX 78759 (in the US); or Pascal 
Faudemay, Masi Labo., Univ. of Paris 6, 4 
Place Jussieu, F-75252 Paris, Cedex 05, 
France (outside the US). 


ICNN 89, Int’l Conf. on Neural Networks, 
June 19-22, Washington, DC. Sponsor: 
IEEE. Contact Nomi Feldman, 3770 Tansy 
St., San Diego, CA 92121, phone (619) 453- 
6222. 


|nv Fourth Structure in Complexity The¬ 
ws' (( ry Conf., June 19-22, Eugene, Ore. 
Cosponsors: Univ. of Oregon, ACM. Contact 
Stephen R. Mahaney, Rm. 2C-454, AT&T 
Bell Labs, 600 Mountain Ave., Murray Hill, 
NJ 07974, phone (201) 582-5613. 


Conf. 89: Graphics Interface 89 and Vi¬ 
sion Interface 89, June 19-23, London, 
Ont., Canada. Sponsors: Canadian Man- 
Computer Communications Society, Cana¬ 
dian Image Processing and Pattern Recogni¬ 
tion Society. Contact Irene Gargantin, Com¬ 
puter Science Dept., Univ. of Western On¬ 
tario, London, Ont., Canada N6A 5B7, 
phone (519) 661-3563. 


Third Electronics Materials and Process 
Conf., June 20-22, Los Angeles. Sponsor: 
Society for the Advancement of Material and 
Process Engineering. Contact Marge Smith, 
SAMPE, PO Box 2459, 843 W. Glentana, 
Covina, CA 91722, phone (818) 331-0616. 


OTM FTCS 19, Int’l Fault-Tolerant Com- 
puting Symp., June 20-23, Chicago. 
Contact S.M. Reddy, FTCS 19, Electrical and 
Computer Engineering Dept., Univ. of Iowa, 
Iowa City, IA 52242, phone (319) 335-5196; 
or Ravi K. Iyer, Coordinated Science Lab, 


Univ. of Illinois, 1101 W. Springfield Ave., 
Urbana, IL 61801, phone (217) 333-9732. 


Third Int’l Conf. on Foundations of Data 
Organization and Algorithms, June 21-23, 

Paris. Sponsor: INRIA. Contact Witold Lit- 
win, INRIA Rocquencourt, c/o Public Rela¬ 
tions Dept., Domaine de Voluceau, 78153 Le 
Chesnay Cedex, France, phone 33 (1) 39-63- 
56-00. 


SIGPlan 89, Conf. on Programming Lan¬ 
guage Design and Implementation, June 
21-23, Portland, Ore. Sponsor: ACM. Con¬ 
tact Bruce Knobe, Prime Computer, Inc., 500 
Old Connecticut Path, Framingham, MA 
01701, phone (508) 879-2960. 

(3w Second Symp. on Computer-Based 
N®^ Medical Systems, June 25-27, Min¬ 
neapolis, Minn. Cosponsors: IEEE, Univ. of 
Minnesota. Contact John M. Long, 2829 
University Ave. SE, #408, Minneapolis, MN 
55414, phone (612) 627-4850; or Bart Galle, 
Continuing Medical Education, Univ. of 
Minnesota, Box 202 UMHC, 420 Delaware 
St. SE, Minneapolis, MN 55455, phone (612) 
626-5525. 

CAR 89, Computer-Assisted Radiol- 

ogy Conf., June 25-28, Berlin. Co¬ 
sponsor: AMK Berlin. Contact Michael L. 
Rhodes, MPDI, 2730 Pacific Coast Hwy., 
Ton-ance, CA 90505, phone (213) 539-5944. 

tgfjh DAC 89, 26th Design Automation 

Conf., June 25-29, Las Vegas. Co¬ 
sponsor: ACM. Contact Michael J. Loren- 
zetti, MCNC, PO Box 12889, Research Tri¬ 
angle Park, NC 27709-2889; or Pat Pistilli, 
MP Associates, 7490 Clubhouse Rd„ Suite 
102, Boulder, CO 80301, phone (303) 530- 
4333. 


gfjb Hot Chips Symp., June 26-27, Palo 
'S' Alto, Calif. Sponsor: IEEE Computer 
Society Technical Committee on Micro¬ 
processors and Microcomputers. Contact 
Robert Stewart, Stewart Research Enter¬ 
prises, 1658 Belvoir Dr., Los Altos, CA 
94022, phone (408) 432-3000. 

tgjjN Workshop on Languages and Archi- 
'-A7 tectures for Automation, June 26-28, 

Madrid. Contact T.C. Ting, Office of the 
Dean, U-237, School of Engineering, Univ. 
of Connecticut, Storrs, CT 06268, phone 
(203) 486-5462. 


Int’l Assoc, of Knowledge Engineers Conf., 
June 26-28, College Park, Md. Cosponsors: 
IAKE, Univ. of Maryland. Contact Fred 
Whiting, IAKE Conf., Georgetown PO Box 
25461, Washington, DC 20007, phone (301) 
231-7826. 


Int’l Conf. on Mathematics of Program 
Construction, June 26-30, Groningen, The 
Netherlands. Contact Jan L.A. van de 
Snepscheut, Mathematics and Computing 
Science Dept., Groningen Univ., PO Box 
800, 9700 AV Groningen, The Netherlands. 

Int’l Conf. on Expert Planning Systems, 
June 27-29, Brighton, England. Sponsor: In¬ 
stitution of Electrical Engineers. Contact 


Conf. Services, IEE, Savoy PI., London 
WC2R 0BL, UK, phone 44 (1) 240-1871, 
ext. 222. 

IFCS 89, Second Conf. of the Int’l Federa¬ 
tion of Classification Societies, June 27-30, 
Charlottesville, Va. Contact IFCS 89, Mathe¬ 
matics Dept., Univ. of Virginia, Charlot¬ 
tesville, VA 22903, phone (804) 924-4919. 


July 1989 


SETSS 90, Seventh Int’l Conf. on Software 
Engineering for Telecommunications 
Switching Systems, July 3-6, Bournemouth, 
England. Sponsor: Institution of Electrical 
Engineering. Contact Conf. Services, IEE, 
Savoy Pl„ London WC2R 0BL, UK, phone 
44 (01) 24-01-871. 

EKAW 89, Third European Knowledge 
Acquisition for Knowledge-Based Systems 
Workshop, July 3-7, Paris. Contact John 
Boose, Advanced Technology Center, Boe¬ 
ing Computer Services, 7L-64, PO Box 
24346, Seattle, WA 98124, phone (206) 865- 
3253; or Brian Gaines, Dept, of Computer 
Science, Univ. of Calgary, 2500 University 
Dr. NW, Calgary, Alta., Canada T2N 1N4, 
phone (403) 220-5901. 


ICALP 89, 16th Colloquium on Automata, 
Languages, and Programming, July 11-15, 

Stresa, Italy. Sponsor: European Assoc, of 
Theoretical Computer Science. Contact Ron- 
chi Della Rocca, Dip. di Informatica, corso 
Svizzera 185, 10149 Torino, Italy, phone 39 
(11) 75-56-77. 


Eighth Australia Conf. on Microelectron¬ 
ics: July 12-14, Brisbane, Australia. Co¬ 
sponsors: IEEE Queensland Section, Univ. 
of Queensland. Contact Microelectronics 89, 
Institution of Engineers, Australia, 11 Na¬ 
tional Circuit, Barton ACT 2600, Australia, 
phone 61 (62) 706-549. 


(3m Symp. on Design and Integration of 
Large Spatial Databases, July 17-18, 

Santa Barbara, Calif. Contact Oliver Gun¬ 
ther, Computer Science Dept., Univ. of Cali¬ 
fornia, Santa Barbara, CA 93106, phone 
(805) 961-3236. 


CASE 89, Third Int’l Workshop on 
N®^ Computer-Aided Software Engineer¬ 
ing, July 17-21, London. Cosponsors: Impe¬ 
rial College of London et al. Contact Elliot 
Chikofsky, Index Technology Corp., 1 Main 
St., Cambridge, MA 02142 (in North Amer¬ 
ica); or John Jenkins, School of Manage¬ 
ment, Imperial College, London SW7 2PG, 
UK (in other regions). 


Third Int’l Conf. on Image Processing, 
July 18-20, Warwick, England. Sponsor: In¬ 
stitution of Electrical Engineers. Contact 
Conf. Services, IEE, Savoy PL, London 
WC2R 0BL, phone 44 (1) 24-01-871, ext. 
222. 


89 VLSI Education Conf. and Exposition, 
July 19-21, Santa Clara, Calif. Contact M. 
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Bush, Conf. Management Services, 5 Cle- 
land PI., Menlo Park, CA 94025, phone 
(415) 329-0510. 

Summer Computer Simulation Conf., July 
24-27, Austin, Texas. Sponsor: Society for 
Computer Simulation. Contact SCS, PO Box 
17900, San Diego, CA 92117-7900, phone 
(619) 277-3888. 

1989 Int’l Computers in Engineering 
Conf., July 30-Aug. 2, Anaheim, Calif. 
Sponsor: ASME. Contact Donald R. Riley, 
Mechanical Engineering Dept., Univ. of 
Minnesota, 111 Church St. SE, Minneapolis, 
MN 55455. 

(^4^) SIGGraph 89, 16th Conf. on Com- 
puter Graphics and Interactive Tech¬ 
niques, July 30-Aug. 4, Boston. Cosponsor: 
ACM. Contact Chris Herat, Javelin Software, 
1 Kendall Square, Bldg. 200, Cambridge, 

MA 02139. 


August 1989 


ftffl Micro 22, 22nd Workshop on Micro- 
programming and Microarchitec¬ 
ture: Aug. 14-16, Dublin, Ireland. Contact 
Gearold R. Johnson, Center for Computer 
Assisted Engineering, Colorado State Univ., 
Fort Collins, CO 80523, phone (303) 491- 
5543. 

Third Pan Pacific Computer Conf., 
Aug. 15-19, Beijing. Cosponsors: Chi¬ 
nese Computer Federation, Chinese Inst, of 
Electronics. Contact Halbrecht Associates, 
1200 Summer St., Stamford, CT 06905, 
phone (203) 327-5630; or Hu Qiheng, Aca¬ 
demia Sinica, Beijing, China, phone 232013. 

VLSI 89, Int’l Conf. on Very Large 
Scale Integration, Aug. 16-18, Mu¬ 
nich, West Germany. Cosponsor: IFIP. Con¬ 
tact VLSI 89, Siemens AG, Otto-Hahn-Ring 
6, 8000 Munich 83, Federal Republic of Ger¬ 
many, phone 49 (89) 63-64-60-38.; or R. Pi- 
loty, Inst, fur Datentechnik, Merkstr. 29, 
Darmstadt, F.R.G., phone 49 (6151) 162- 
076. 

ITC 89, Int’l Test Conf., Aug. 27-31, 

Washington, DC. Contact Doris Tho¬ 
mas, ITC 89, PO Box 264, Mt. Freedom, NJ 
07970, phone (201) 895-5260. 

Congress 89, 11th World Computer 
Congress, Aug. 28-Sept. 1, San Fran¬ 
cisco. Sponsor: IFIP. Contact Congress 89, 
PO Box 18-P, Denver, CO 80218, phone 
(303) 831-6338; Adrian J. Basili, AT&T, 30 
Knightsbridge Rd., Piscataway, NJ 08854; or 
Stephen Yau, Univ. of Florida, CIS Dept., 
Rm. 301, Gainesville, FL 32611, phone 
(904) 335-8006. 


September 1989 


Calif. Contact Algirdas Avizienis, Computer 
Science Dept., Univ. of California at Los 
Angeles, 4731G Boelter Hall, Los Angeles, 
CA 90024, phone (213) 825-3028. 

Canadian Conf. on Electrical and 
Computer Engineering, Sept. 17-20, 

Montreal. Cosponsor: Canadian Society of 
Electrical Engineering. Contact Paul E. Al¬ 
lard, Transportation Development Ctr-Trans- 
port Canada, 200 Rene-Levesque Blvd. 

West, Suite 601, West Tower, Montreal, 

Que., Canada, phone (514) 283-0004. 

Compsac 89, 13th Int’l Computer 
Software and Applications Conf., 
Sept. 18-22, Kissimmee, Fla. Contact IEEE 
Computer Society, 1730 Massachusetts Ave. 
NW, Washington, DC 20036-1903, phone 
(202) 371-0101. 

ASIC Seminar and Exhibit, Sept. 25- 

28, Rochester, N.Y. Contact Lynne M. 
Engelbrecht, 170 Mt. Read Blvd., Rochester, 
NY 14611, phone (716) 328-2310; or Jon K. 
Edwards, Eastman Kodak, Dept. 434, FI. 1, 
Bldg. 9, Rochester, NY 14650, phone (716) 
726-9222. 

(Qjl Computational Intelligence 89 

Symp., Sept. 25-29, Milan, Italy. Co¬ 
sponsor: ACM. Contact Luc Steels, Free 
Univ. Brusselles, AI Lab, Pleinlaan 2, Ge- 
louw K 2 B-1050, Brussels, Belgium. 

Performance Evaluation, Reliability, 
and Exploitation of Computer Sys¬ 
tems, Sept. 26-29, Walbrzych, Poland. Spon¬ 
sors: Polish Informatic Society et al. Contact 
George J. Anders, Stations and Underground 
Section, Electrical Research Dept., Ontario 
Hydro, 800 Kipling Ave., KR 151, Toronto, 
Ont., Canada M8Z 5S4, phone (416) 231- 
4111. 

Second IEEE Workshop on Worksta- 
tion Operating Systems, Sept. 27-29, 

Pacific Grove, Calif. Contact Joseph Boykin, 
Encore Computer, 257 Cedar Hill St., 
Marlborough, MA 01752, phone (617) 460- 
0500. 


October 1989 


tfhb ICCD 89, IEEE Int’l Conf. on Com- 
puter Design, Oct. 2-4, Cambridge, 
Mass. Contact Sumit Das Gupta, IBM, Bldg. 
306, ZIP 3A1, Hopewell Junction, NY 
12533, phone (914) 894-0540; or Giovannie 
DeMicheli, Stanford Univ., Center for Inte¬ 
grated Systems, Rm. 129, Stanford, CA 
94305, phone (415) 725-3632. 

Second Int’l Workshop on Software 
Configuration Management, Oct. 3- 

6, Princeton, NJ. Cosponsors: ACM, 
Gesellschaft fur Informatik. Contact Thomas 
Murphy, Siemens Research, 755 College Rd. 
E, Princeton, NJ 08540i phone (609) 734- 
6560. 


Oct. 4-6, Cambridge, Mass. Cosponsors: 
INCA et al. Contact John Miller, INCA, PO 
Box 2, Dun Laoghaire, County Dublin, Ire¬ 
land, phone 353 (1) 772-941. 

Workshop on Experiences with 
^4/ Building Distributed and Multi¬ 
processor Systems, Oct. 5-6, Fort Lauder¬ 
dale, Fla.. Cosponsors: Usenix et al. Contact 
George W. Leach, PO Box 2826, MS LG- 
129, Largo, FL 34649-2826, phone (813) 
530-2376. 

Eighth Symp. on Reliable Distributed 
Systems, Oct. 10-12, Seattle. Contact 
Jane W.S. Liu, Computer Science Dept., 

Univ. of Illinois, Urbana, IL 61801, phone 
(217) 333-6769 or 0135. 

14th Conf. on Local Computer Net- 
works, Oct. 10-12, Minneapolis. Con¬ 
tact Ron Rutledge, Martin Marietta Energy 
Systems, Oak Ridge National Lab, Oak 
Ridge, TN 37831-6271, phone (615) 576- 
7643. 

Fifth Int’l Software Process Work- 
shop, Oct. 10-13, Kennebunkport, 
Maine. Cosponsors: Rocky Mountain Inst, of 
Software Engineering et al. Contact De- 
wayne Perry, AT&T Bell Labs, Rm. 3D-454, 
600 Mountain Ave., Murray Hill, NJ 07974, 
phone (201) 582-2529. 

Fourth Int’l Workshop on High- 
Level Synthesis, Oct. 15-18, Ken¬ 
nebunkport, Maine. Cosponsor: ACM. Con¬ 
tact Gaetano Borriello, Computer Science 
Dept., FR 35, Univ. of Washington, Seattle, 
WA 98195, phone (206) 543-1695. 

OTlt Data and Knowledge Systems for 
Manufacturing and Engineering, 

Oct. 16-18, Gaithersburg, Md. Cosponsor: 
ACM. Contact Lawrence A. Rowe, Computer 
Science Div.-EECS, Univ. of California, 
Berkeley, CA 94720. 

CSM 89, Conf. on Software Mainte- 
nance, Oct. 16-19, Pensacola, Fla. 
Contact CSM 89, IEEE Computer Society, 
1730 Massachusetts Ave. NW, Washington, 
DC 20036-1903, phone (202) 371-0101; or 
Wilma Osborne, NIST, Bldg. 225, Rm. 

B266, Gaithersburg, MD 20899, phone (301) 
975-3339. 

IEEE Int’l Workshop on Tools for 
Artificial Intelligence, Oct. 23-25, 

Fairfax, Va. Contact Nikolas G. Bourbakis, 
Machine Vision Research Lab, ECE Dept, 
SITE, George Mason Univ., 4400 University 
Dr., Fairfax, VA 22030, phone (703) 425- 
3930. 

Int’l Workshop on Defect and Fault 
Tolerance in VLSI Systems, Oct. 23- 
25, Tampa, Fla. Contact Charles H. Stapper, 
Dept. A23, Bldg. 861-1, IBM, Essex Junc¬ 
tion, VT 05452, phone (802) 769-6655. 

23rd Asilomar Conf. on Signals, Sys- 
terns, and Computers, Oct. 30-Nov. 1, 

Pacific Grove, Calif. Cosponsors: Naval 
Postgraduate School, San Jose State Univ. 
Contact John T. Rickard, Orincon, 9363 
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ftffl Third IFAC Workshop on Experi- 
ence with the Management of Soft¬ 
ware Projects, Oct. 30-Nov. X, West Lafay¬ 
ette, Ind. Cosponsors: Purdue Univ. et al. 
Contact Frederic J. Mowle, School of Electri¬ 
cal Engineering, Purdue Univ., West Lafay¬ 
ette, IN 47907, phone (317) 494-3440. 

|£§^j) FedCASE 89, Federal CASE Conf., 
vAz Oct. 30-Nov. 2, Gaithersburg, Md. 
Sponsor: Nat’l Inst, of Standards and Tech¬ 
nology. Contact Maggie H. Law or Wilma 
M. Osborne, NIST, Technology Bldg., Gaith¬ 
ersburg, MD 20899. 

FOCS 89, 30th Foundations of Com- 
W 1 puter Science Conf., Oct. 30-Nov. 3, 

Research Park, N.C. Contact FOCS 89, IEEE 
Computer Society, 1730 Massachusetts Ave. 
NW, Washington, DC 20036-1903, phone 
(202) 371-0101. 


November 1989 


ICCAD 89, IEEE Int'l Conf. on Com- 
N5? puter-Aided Design, Nov. 6-9, Santa 
Clara, Calif. Cosponsor: IEEE Circuits and 
Systems Society. Contact IEEE Computer 
Society, 1730 Massachusetts Ave. NW, 
Washington, DC 20036-1903, phone (202) 
371-1013. 

Supercomputing 89, Nov. 13-17, 

Reno, Nev. Cosponsor: ACM. Contact 
F. Ron Bailey, MS 258-5, NASA Ames Re¬ 
search Center, Moffett Field, CA 94035, 
phone (415) 694-4500. 

^ IEEE Workshop on Interpretation of 
3D Scenes, Nov. 27-29, Austin, Texas. 
Contact Anil K. Jain, Computer Science 
Dept., Michigan State Univ., East Lansing, 
MI 48824, phone (517) 353-5150. 


Austin, TX 78759, phone (512) 343-0860; 
Jean-Marie Nicholas, ECRC Arabellastr. 17, 
8000 Munich 81, FRG, phone 49 (89) 926- 
99-110; or Shojiro Nishio, Information and 
Computer Sciences Dept., Faculty of Engi¬ 
neering Science, Osaka Univ., Toyonaka, 
Osaka, 560 Japan, phone 81 (6) 853-5737. 

10th Real-Time Systems Symp., Dec. 

5-7, Los Angeles. Contact Al Mok, 
Computer Science Dept., TAY 3-140C, 

Univ. of Texas at Austin, Austin, TX 78712, 
phone (512) 471-9542. 

Sigsoft 89, Third Testing, Analysis, 

and Verification Symp., Dec. 6-8, 

Key West, Fla. Cosponsor: ACM. Contact 
Richard A. DeMillo, Purdue Univ., Com¬ 
puter Science Dept., West Lafayette, IN 
47907, phone (317) 494-7823. 

Third Int’l Workshop on Petri Nets 

and Performance Models, Dec. 11-13, 

Kyoto, Japan. Cosponsors: Society of Instru¬ 
ment and Control Engineers et al. Contact 
Shojiro Nishio, Information and Computer 
Sciences Dept., Faculty of Engineering Sci¬ 
ence, Osaka Univ., Toyonaka, Osaka, 560 
Japan, phone 81 (6) 853-5737. 

Int’l Conf. on CAD/CAM and Ad- 
'■=7 vanced Manufacturing Technology, 
Dec. 19-21, Jerusalem, Israel. Cosponsor: Is¬ 
rael Society for CAD/CAM. Contact Law¬ 
rence R. Odess, Ortra, PO Box 50432, 61500 
Tel Aviv, Israel, phone 972 (3) 971-3991 or 
664-825. 


January 1990 


HICSS 23, 23rd Hawaii Int’l Conf. 
N5?' on System Sciences, Jan. 3-6, Kona, 
Hawaii. Cosponsor: ACM. Contact Luqi, 
Computer Science Dept., Naval Postgraduate 
School, Monterey, CA 93943, phone (408) 
646-2735. 


March 1990 


yra Parbase 90, Int’l Conf. on Databases, 
'sA7 Parallel Architectures, and their Ap¬ 
plications, March 6-9, Miami Beach. Co¬ 
sponsors: Florida International Univ. et al. 
Contact Parbase 90, School of Computer Sci¬ 
ence, Florida International Univ., Miami, FL 
33199, phone (305) 554-3429 or 3386. 

EDAC 90, European Design Automa- 
^A7 tion Conf., Mar. 12-15, Glasgow, 
Scotland. Contact Gordon Adshead, ICL, 26 
Albany St„ Edinburgh, EH1 3QH, UK, 
phone 44 (61) 223-1207. 

IEEE Int’l Conf. on Computer Lan- 
vU' guages, Mar. 12-16, New Orleans. 
Contact Boumediene Belkouche, Computer 
Science Dept., Tulane Univ., 301 Stanley 
Thomas Hall, New Orleans, LA 70118, 
phone (504) 865-5840. 

^ IPCCC, Ninth IEEE Int’l Phoenix 

Conf. on Computers and Communi¬ 
cations, Mar. 21-23, Scottsdale, Ariz. Con¬ 
tact Forouzan Golshani, Computer Science 
Dept., Arizona State Univ., Tempe, AZ 
85287, phone (602) 965-2855. 

ICSE 12, 12th Int’l Conf. on Soft- 
'A7 ware Engineering, Mar. 26-30, Nice, 
France. Cosponsors: ACM et al. Contact 
Francois-Regis Valette, CERT/DERI, PO 
Box 4026-2, Ave. Edouard Belin-31055 
Toulouse, France, phone (33) 61-55-71-11; 
ICSE 12, AFCET, 156 Bd. Pereire, 75017 
Paris, France; or IEEE Computer Society, 
1730 Massachusetts Ave. NW, Washington, 
DC 20036-1903, phone (202) 371-0101. 

1990 Int’l Conf. on Extending Data- 
'A? base Technology, Mar. 26-30, Venice, 
Italy. Cosponsors: EDBT Foundation et al. 
Contact Michael L. Brodie, Intelligent Data¬ 
base Systems Dept., GTE Labs, 40 Sylvan 
Rd„ MS 62, Waltham, MA 02254, phone 
(617) 466-2256. 


December 1989 


y fy WSC 89, Winter Simulation Conf., 
NS7 Dec. 3-6, Washington, DC. Cospon¬ 
sors: Society for Computer Simulation et al. 
Contact Philip Heidelberger, IBM Research 
Div., T.J. Watson Research Center, Haw¬ 
thorne, PO Box 704, Yorktown Heights, NY 
10598, phone (914) 789-7156. 

OTm Fifth Aerospace Computer Security 
Applications Conf., Dec. 4-8, Tucson, 
Ariz. Contact Marshall Abrams, Mitre Corp., 
7525 Colshire Dr., McLean, VA 22102, 
phone (703) 883-6938. 

First Int’l Conf. on Deductive and 
Object-Oriented Databases, Dec. 4-6, 

Kyoto, Japan. Cosponsors: Information Pro¬ 
cessing Society of Japan et al. Contact Won 
Kim, MCC, 3500 W. Balcones Center Dr., 


February 1990 


April 1990 


Sixth Int’l Conf. on Data Engineer- 
^=7 ing, Feb. 5-9, Los Angeles. Contact 
Joseph E. Urban, College of Engineering, 
Univ. of Miami, PO Box 248294, Coral 
Gables, FL 33124, phone (305) 284-2404. 

Compcon Spring 90, Feb. 26-Mar. 2, 

^=7 San Francisco. Contact Kenichi Miura, 
Computational Research Dept., MS B2-7, 
Fujitsu America, 3055 Orchard Dr., San 
Jose, CA 95134-2017, phone (408) 432- 
BOO, ext. 5408 or 5723. 

Third Int’l Software for Strategic 
N57 Systems Conf., Feb. 27-28, Huntsville, 
Ala. Cosponsors: IEEE Computer Society 
Huntsville Chapter, Univ. of Alabama in 
Huntsville, Continuing Education Div., Tom 
Bevill Center 285, Huntsville, AL 35899, 
phone (800) 448-4035 or (205) 895-6372. 


OTm IEEE Infocom 90, Apr. 2-5, San Fran- 
'N=7 cisco. Contact Infocom 90, IEEE Com¬ 
puter Society, 1730 Massachusetts Ave. NW, 
Washington, DC 20036-1903, phone (202) 
371-1013. 

First Int’l Conf. on Systems Integra- 
^A7 tj 0Il! Apr. 23-26, Morristown, N.J. Co¬ 
sponsors: New Jersey Inst, of Technology et 
al. Contact Peter A. Ng, Computer and Infor¬ 
mation Science Dept., New Jersey Inst, of 
Technology, Newark, NJ 07102, phone (201) 
596-3387. 

COIS 90, Conf. on Office Informa- 
^=7 tion Systems, Apr. 25-27, Cambridge, 
Mass. Cosponsor: ACM. Contact Robert B. 
Allen, 2A-367, Bellcore, 445 South St., Mor¬ 
ristown, NJ 07960-1910, phone (201) 829- 
4280 or 4315. 
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OSI/NETWORK 

MANAGEMENT 


UNiSYS Networks 


Unisys has been committed, as a 
fundamental strategy, to making its infor¬ 
mation systems products operate optimally 
in highly networked, multi-vendor en¬ 
vironments. Customers are increasingly 
asking computer vendors like Unisys to 
design, build, and help manage their 
total information networks. 

And now, Unisys has made a major 
commitment to Network Management 
systems development. As a leader in 
OSI-based product development, it’s 
only natural that we build on the OSI 
Management Framework and Protocols as 
a base for our new generation of products. 

We recognize that working in a 
smaller team environment is the key to 
innovation. Our new facility in Neptune, 
New Jersey is dedicated to the proposi¬ 
tion that a team of the right people, 
equipped with state-of-the-art software 
tools in a workstation-based develop¬ 
ment center, will produce the best 
systems in the industry. 

If you want to have an impact on 
the way OSI and Network Management 
are implemented, both at Unisys and 
throughout the industry, we’d like to talk 
to you. And if you understand how 
standards and architecture relate to 
products, we speak your language! 

We are seeking a number of highly 
qualified candidates in the following areas: 

Network Management 
Architecture 

We are seeking both lead and con¬ 
tributing members for an Architecture 
group responsible for definition and 
documentation of both abstract and 
product-specific architectures. Concen¬ 
tration will be on OSI-based Network 
Management applied to a diverse set of 
communications and computer system 
architectures. Standards involvement will 
be a plus as well as a record of suc¬ 
cessful transfer of architecture to pro¬ 
duct design. 

Distributed 
Systems S/W Design 

We are seeking both lead and con¬ 
tributing members for a System Design 
group responsible for definition and 
documentation of product-specific ar¬ 


chitectures. Concentration will be on 
OSI-based Network Management applied 
to a diverse set of communications and 
computet system architectures. Suc¬ 
cessful candidates will have a back¬ 
ground in distributed systems including 
workstation-based applications develop¬ 
ment. Target environments will span 
workstations, Unix-based minicomputers 
and mainframes. 

S/W Development 
Methodology 

Be responsible for definition and im¬ 
plementation of a state-of-the-art soft¬ 
ware development methodology for a 
project developing a distributed network 
management applications system based 
on graphics workstations. Respon¬ 
sibilities will involve development of a 
plan for staged introduction of new soft¬ 
ware tools (CASE), vendor evaluations, 
tools selection, and installation and 
evolution of the environment. This is an 
opportunity for the successful candidate 
to operate in a fast-paced, aggressive 
organization with a strong commitment 
to building the best in software develop¬ 
ment environments. 

Software Development 

As Senior Staff Engineer you will 
assume responsibility for our application 
development strategy. You will deal with 
the challenges of implementing an ap¬ 
plication subsystem in a distributed, 
heterogenous network management 
system. A strong system design 
background to handle the intricacies of 
configuration, fault, performance, ac¬ 
counting and security management in 
an OSI framework is required for this 
position. Also required are an advanced 
degree in computer science, 9+ years 
of development experience. Network 
management systems experience 
strongly preferred. 

We offer highly competitive com¬ 
pensation and a generous relocation 
package. For further information, please 
submit your resume in complete con¬ 
fidence to: Human Resources, Unisys 
Network Management Development 
Laboratory, 3535 Route 66, Neptune, 

New Jersey 07753. We are an equal op¬ 
portunity employer m/f/h/v. 

UMSYS 












CAREER OPPORTUNITIES 


RATES: $12.00 per line. $120 
minimum charge (up to ten lines). 
Average five typeset words per line, eight 
lines per column inch. Add $10 for box 
number. Send copy at least one month 
prior to publication to: Heidi Rex or 
Marian Tibayan, Classified Advertis¬ 
ing, COMPUTER Magazine, 10662 Los 
Vaqueros Circle, Los Alamitos, CA 
90720; (714) 821-8380. 

In order to conform to the Age Discrimi¬ 
nation in Employment Act and to dis¬ 
courage age discrimination, COMPUTER 
may reject any advertisement containing 
any of these phrases or similar ones: 
“...recent college grads...,” "...1-4 years 
maximum experience..., ” “...up to 5 years 
experience...,” or “...10 years maximum 
experience.” COMPUTER reserves the 
right to append to any advertisement, 
without specific notice to the advertiser, 
“Experience ranges are suggested mini¬ 
mum requirements, not maximums.” 
COMPUTER assumes that, since adver¬ 
tisers have been notified of this policy in 
advance, they agree that any experience 
requirements, whether stated as ranges or 
otherwise, will be construed by the reader 
as minimum requirements only. 


ACADEMIA S1NICA 
Taiwan, Republic of China 
Institute of Information Science 

Applications are invited for research posi¬ 
tions in Institute of Information Science, 
Academia Sinica. Ph.D. in computer related 
fields required. Demonstratable research 
ability necessary. Applicants for senior posi¬ 
tions must have proven research record. All 
fields in computer science are welcome. 

The Institute offers a good research en¬ 
vironment. No duty of teaching. Facilities in¬ 
clude 3 VAX’s, 4 SUN’s (including a SUN- 
4/260), 2 E&S workstations, a lot of small 
computers and an easily accessible ETA-10Q 
super computer at Academia Sinica. Two- 
year expansion plan will strengthen our facil¬ 
ities with an IRIS and a multi-processor 
machine. 

Interested people please send application 
to Dr. Y.S. Kuo, Acting Director, Institute of 
Information Science, Academia Sinica, Tai¬ 
pei, Taiwan, Republic of China, e-mail ad¬ 
dress: WT6B0001@TWNMOE10.BITNET. 
FAX: (011-886-2) 782-4814. 


DIANETICS 

How can you realize your mind’s poten¬ 
tial? Discover and use Dianetics,® the totally 
practical science of the mind, by bestselling 
author L. Ron Hubbard. Order your copy 
today. Call now: 1-800-367-8788. Hard¬ 
back $25.00. Dianetics is a registered 
trademark. 


STANFORD UNIVERSITY 

The Department of Electrical Engineering 
of Stanford University is seeking candidates 
for a tenured or tenure-track position in 
Fiber-Optic Telecommunications. The field 
of interest is interpreted broadly to include 
both systems and device aspects of optical 
communications. However, the individual 
we seek should have greatest strength and 
experience with systems, and in particular 
should be knowledgeable of the commercial 
telecommunications industry and its needs. 
Candidates should have excellent knowl¬ 
edge of the latest theoretical results and a 
proven skill in implementing such knowl¬ 
edge in “proof of concept” demonstrations. 
Simultaneously, he or she should have a 
good knowledge of the relevant device 
physics and technology. The appointment 
can be made at either a junior or a senior 
level, but the Department prefers a seasoned 
individual, possibly with industrial experi¬ 
ence, and having the potential to lead a 
larger telecommunications effort at Stanford. 
Applicants should have an earned Ph.D., 
demonstrated research ability, and a strong 
interest in graduate and undergraduate 
teaching. Stanford University is an Equal 
Opportunity Employer and welcomes appli¬ 
cations from women and members of minor¬ 
ity groups. Please submit, no later than May 
15, 1989, a detailed resume, a publication 
list, and the names of five references to Pro¬ 
fessor Allen Peterson, Chairman, Search 
Committee, Durand 227, Department of 
Electrical Engineering, Stanford University, 
Stanford, California 94305-4055. 


STATE UNIVERSITY OF NEW YORK 
AT BINGHAMTON 

Data Base or Software Engineering, 

and Theoretical Computer Science 

The Department of Computer Science of 
the State University of New York at Bing¬ 
hamton seeks to fill a leadership role. Prefer 
Associate or full Professor level with proven 
expertise in data base systems or software 
engineering, and a strong orientation toward 
theoretical computer science. Assistant Pro¬ 
fessor or long term visiting appointment may 
be considered. 

The Department offers programs leading 
to the B.S., and M.S., and Ph.D. degrees. 
High technology computer-oriented com¬ 
panies in the local area, such as IBM, GE 
and Universal Instruments, provide oppor¬ 
tunities for professional development both 
on and off campus. 

Nominations or applications should be 
sent to Dr. Michael F. McGoff, Acting Chair¬ 
man, Department of Computer Science, 
The Thomas J. Watson School of Engineer¬ 
ing, Applied Science, and Technology, 
SUNY-Binghamton, Binghamton, NY 
13901: (607) 777-6204; mmcgoff@bing- 

SUNY is an equal opportunity affirmative 
action employer. 


RENSSELAER POLYTECHNIC 
INSTITUTE 

The Computer Science Department in¬ 
vites applications for tenure-track faculty 
positions at all academic ranks. Research, 
visiting and postdoctoral appointments may 
also be available. Applicants should have a 
Ph.D. in Computer Science (or a related 
area) and a commitment to excellence in 
teaching and research. Preferred research 
interests are parallel computation, database 
systems, computer graphics, computer vi¬ 
sion, image processing, VLSI systems and 
symbolic computation; however, all areas 
will be considered. The department offers 
B.S., M.S., and Ph D. degrees in Computer 
Science and has excellent computing facili¬ 
ties. Send resumes and at least three refer¬ 
ences to Joseph E. Flaherty, Chairman, De¬ 
partment of Computer Science, Rensselaer 
Polytechnic Institute, Troy, New York 
12180-3590. Rensselaer is an Equal Oppor¬ 
tunity/Affirmative Action Employer. 


UNIVERSITY OF VERMONT 

The Department of Computer Science 
and Electrical Engineering has visiting faculty 
openings for September, 1989, in computer 
science, A doctorate in Computer Science, 
or the equivalent is required. The level of 
assistant or associate professor will be depen¬ 
dent upon the candidates qualifications. The 
responsibilities include teaching in main¬ 
stream computer science at both the under¬ 
graduate and graduate level in two or more 
of the following areas: operating systems, 
computer architecture, analysis of algo¬ 
rithms, computability theory, programming 
languages, language translators, as well as 
the presentation of an advanced graduate 
course or seminar. Computing facilities for 
both teaching and research are extensive. In 
particular, the Division of Engineering, 
Mathematics, and Business Administration 
supports an extensive UNIX-based com¬ 
puting facility, including a DEC VAX-11/ 
780, a DG MV-10000, a Sun 3/280, a Sun 
4/280, and a four-processor Encore 
Multimax, as well as numerous smaller 
machines and workstations, all intercon¬ 
nected by an extensive broadband and 
ethernet network. High technology com¬ 
panies in the area include IBM, DEC, GE 
and Simmonds Precision. The University of 
Vermont is an Affirmative Action Equal Op¬ 
portunity Employer and encourages applica¬ 
tions from women and members of minority 
groups. Applications will be accepted until 
positions are filled. Please send full resume, 
including information on teaching capabili¬ 
ties and research interests, as well as the 
names and addresses of three references to: 
Dr. Kenneth Golden, Chairperson; Univer¬ 
sity of Vermont; Department of Computer 
Science and Electrical Engineering; Votey 
Building; Burlington, VT 05405; (802) 656- 
3330. CSnet: cssearch@uvm.edu USEnet: 

. . . uunetluvm-genlcssearch 
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UNIVERSITY OF SOUTHERN 
CALIFORNIA 

Post Doctoral Research Position 

Electrical Engineering Department, Uni¬ 
versity of Southern California. Temporary 
full time position for two years commencing 
in September 1989, with possibility of exten¬ 
sion contingent upon funding. Salary 
$44,000 to $50,000 per annum, dependent 
on qualifications. Assist in development of 
knowledge based system for design of test¬ 
able digital systems. Ph.D. degree in CS or 
Computer Engineering, research experience 
in VLSI design, testing and design for test, 
and a strong background in software engi¬ 
neering. Send resume to Professor M.A. 
Breuer, Electrical Engineering-Systems De¬ 
partment, University of Southern California, 
Los Angeles, CA 90089-0781. USC is an 
equal opportunity, affirmative action 
employer. 


SYSTEMS ANALYST 

Exam, evaluate and analyze multi-level 
application systems; Maintain and upgrade 
Data General MV10000 Comp, systems 
using AOS/VS operating system and CLI 
macro. Evaluate, improve existing or de¬ 
velops new systems to meet current and pro¬ 
jected needs. Conduct reviews to insure 
functional/projected systems are applied as 
designed and functioning satisfactorily. Inter¬ 
face with users; write users’ manual, train 
users. Must know 1COBOL; must communi¬ 
cate effectively; Familiar with Data General 
MV10000 computer system and multi-level 
marketing application system. Requires 2 
years experience with B.S. in Computer 
Science or M.I.S. Will accept M.S. in lieu of 
experience. $3,071/mo. Job and interview 
in Torrance, CA. Send ad and resume to 
Job *NOF 196, P.O. Box 9560, Sacramen¬ 
to, CA 95823-0560 not later than 5/31/89. 


COMPUTATIONAL LINGUIST 

COMPUTATIONAL LINGUIST for elec¬ 
tronic publishing firm in Southeast Ohio. 
Perform major experiments and base re¬ 
search to validate and extend natural lan¬ 
guage work, grammar recognition tools, 
sentence syntax, and discourse modeling 
with high emphasis on "proper noun” 
related research. Requires Ph.D. or ABD in 
Linguistics. As part of Ph.D. academic pro¬ 
gram, applicants must have taken for credit, 
or audited at least 5 courses in computational 
linguistics. Must also have presented or be 
preparing for presentation a Ph.D. thesis in 
the area of computational linguistics. It also 
requires a Masters in either Foreign Lan¬ 
guage or Bilingual Education or in Teaching 
English as a Foreign Language. Must have 
six months research experience, but no ex¬ 
perience required in the job offered. 40 
hrs/wk., 9am-5pm, $2,670/month. Quali¬ 
fied applicants please reply immediately with 
resume to R. Lechler, 30*1186116, Ohio 
Bureau of Employment Services, P.O. Box 
1618, Columbus, Ohio 43216. 


BALL STATE UNIVERSITY 
MUNCIE, IN 
Computer Science 

Faculty position available Fall 1989 in any 
major area of computer science. Back¬ 
ground in artificial intelligence, communica¬ 
tion, software engineering, or operating 
systems preferred. Faculty will teach com¬ 
puter science courses for masters degree and 
undergraduate students. An active scholar¬ 
ship program is expected. Minimum Qualifi¬ 
cations: Ph.D. in computer science or Ph D. 
in closely related field with minimum of a 
masters in computer science; ABD accept¬ 
able if degree is completed by Fall 1990. 
Preferred Qualifications: Ph.D. in computer 
science; at least five years experience in soft¬ 
ware development and teaching; excellent 
teaching record and several publications. 
Send resume, three letters of reference and 
official transcripts to Dr. Earl H. McKinney, 
Chairperson of Search and Selection Com¬ 
mittee, Department of Computer Science, 
Ball State University, Muncie, IN 47306. 
Review of applications will begin May 15, 
1989 and continue until the position is filled. 

Ball State University Practices Equal Op¬ 
portunity in Education and Employment. 


ROCHESTER INSTITUTE 
OF TECHNOLOGY 
SCHOOL OF COMPUTER SCIENCE 
DEPARTMENT OF APPLIED 
COMPUTER STUDIES 
Software Engineering Position 

Visiting or Tenure Track faculty position 
available for individual who has experience 
in the instruction of Software Engineering 
topics, both managerial and technical. 

Ph.D. or Master’s (with professional ex¬ 
perience) degree in appropriate discipline re¬ 
quired. Duties will include teaching at the 
graduate level (M.S.) as well as applied 
research in Software Engineering. 

Send resume to Prof. Guy Johnson, De¬ 
partment of Applied Computer Studies, 
1 Lomb Memorial Drive, RIT, Rochester, 
New York, 14623. RIT is an equal oppor¬ 
tunity affirmative action employer. 


UNIVERSITY OF THE DISTRICT 
OF COLUMBIA 
Faculty Positions in 
Computer Science 

The University of the District of Columbia 
invites applications for faculty positions in 
Computer Science. A Ph.D. required for as¬ 
sociate and full professorships. Master’s 
degree plus experience may be considered. 
Areas of specialization needed include: 
Compiler Design and Theory, File Manage¬ 
ment Design, Computer Architecture, Micro¬ 
processor Applications, and Data Structures. 
Salary and rank depend on qualifications. 
Submit complete resume to Ms. Christine 
Poole, Office of Personnel Management and 
Development, University of the District of 
Columbia, 4200 Connecticut Avenue, N.W., 
Washington, D.C. 20008. An equal oppor¬ 
tunity, affirmative action employer. 


COMPUTER APPLICATIONS 
ENGINEER 

COMPUTER APPLICATIONS ENGI¬ 
NEER—for R&D firm in central OH to 
study, propose and design high performance 
and high availability, distributed processing 
architectures and features to maintain 
superior packet switching product perfor¬ 
mance and economic competitiveness using 
modeling technologies and analytical 
methodologies; evaluate performance and 
reliability of hardware and software in real¬ 
time computer systems. Requires a Ph.D. in 
Computer Engineering or in Electrical Engi¬ 
neering with coursewotk in computer archi¬ 
tecture design and network, traffic, queueing 
and modeling theories; and one year experi¬ 
ence in job described or one year computer 
applications engineering experience perfor¬ 
ming research or teaching at a college/uni¬ 
versity. 40 hours per week, (work schedule: 
7:45am to 4:30pm). Salary is $52,500 per 
year. Qualified applicants reply immediately 
with resume to: R. Lechler, JO. *1167382, 
Ohio Bureau of Employment Services, P.O. 
Box 1618, Columbus, OH 43216. 


ENGINEER 

Engineer for Columbus, Ohio, manufac¬ 
turer to implement computer-integrated 
manufacturing system including installing 
and maintaining warehousing and schedul¬ 
ing system; analyze production methods, 
flow, equipment; install production planning 
and monitoring system; use IBM 38, RPC 
III, AUTOCAD, SAS, CAM & SLAM. Re¬ 
quires B.S, in Mechanical Engineering and 
18 months experience in job described, OR 
an M.S. In Industrial Engineering (including 
projects using CAM, SLAM, IBM hardware) 
and 6 months experience using SAS. 40hr/ 
wk, 9am-6pm. $28,025/yr. Qualified appli¬ 
cants reply immediately with resume to R. 
Lechler, JO*l 167313, Ohio Bureau of 
Employment Services, P.O. Box 1618, Col¬ 
umbus, OH 43216. 


TRINITY COLLEGE 
Computer Science 

Pending approval by the Board of Trustees, 
applications are invited for a tenure track 
position in Computer Science in the Depart¬ 
ment of Engineering and Computer Science 
at Trinity College starting in January 1990. 
The position involves undergraduate and 
graduate instruction and research. A doc¬ 
toral degree in Computer Science or equiva¬ 
lent is required. Applicants will be con¬ 
sidered in all areas of computer science that 
complement or strengthen our current cur¬ 
ricular/research programs. We are inter¬ 
ested in receiving applications from qualified 
women and minorities. Trinity College is an 
equal opportunity/affirmative action em¬ 
ployer. Please send resume to Professor 
Joseph D. Bronzino, Chairman, ECS De¬ 
partment, Trinity College, Hartford, CT 
06106. Consideration of applications will 
begin on May 1, 1989 and the search will re¬ 
main open until the position is filled. 
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UNIVERSITY OF MINNESOTA- 
DULUTH 

COMPUTER SCIENCE: Tenure-track or 
tenured associate professor for fall 1989. 
Duties: teach 6-8 hours per quarter of 
graduate or undergraduate. CS courses, 
especially operating systems, compilers, net¬ 
works, and systems software. Supervise 
graduate theses. Conduct research in CS. 
Share in normal faculty administration 
duties. QUALIFICATIONS: Ph.D. in CS, 
or, in a closely related area together with a 
master’s degree or two year’s experience in 
CS (preference will be given to a Ph.D., in 
CS). Four year’s experience in CS and pro¬ 
fessional distinction in research. Demon¬ 
strated evidence of effective teaching and 
communication skills appropriate to a faculty 
position is required. Tenured: six year’s ex¬ 
perience in CS in an academic institution, 
distinction in teaching and research. Prefer¬ 
ence will be given to candidates with ex¬ 
perience teaching in the areas listed above. 
Deadline: June 15, 1989. Send resume and 
three letters of reference to: Keith Pierce, 
Univefsity of Minnesota-Duluth, Computer 
Science Department, Duluth, MN 55812. 
The University of Minnesota is an equal op¬ 
portunity educator and employer and specif¬ 
ically invites and encourages applications 
from women and minorities. 


ADVANCED TECHNOLOGY CENTER 
ERSO/ITRI, Taiwan 
Republic of China 

Applicants are invited for research posi¬ 
tions of the Advanced Technology Center, 
ESRO/ITRI of Hsinchu, near the Science- 
based Park (Taiwan’s Silicon Valley). A 
Ph D. (or equivalent) in a computer related 
field is required. Demonstrable research 
ability is necessary. Applicants for senior 
positions should have a proven research 
record and management experience. 

ATC was established in 1987 to pursue 
R&D of advanced technologies relevant to 
the computer industry in ROC. A five-year 
growth plan is designed to attract the best 
research talents to pursue knowledge and 
technologies, until they take root, sprout 
new advances, and reach a leading/com¬ 
petitive edge for ROC. Current emphasis at 
ATC include AI, parallel processing, CAD, 
CIM, software engineering, communication 
networks, and supercomputing. 

ATC offers an excellent research environ¬ 
ment unique in ROC. Computing facilities 
include VAXs, SUNs (4/260 and 3/60s), a 
TI Explorer LX II Lisp machine, a 20-proces¬ 
sor transputer, and a PC/AT class worksta¬ 
tion at everyone’s desk for both local com¬ 
putation and network access. 

Interested applicants should send a com¬ 
plete resume, three references, significant 
publications and relevant supporting materi¬ 
al to either ATC (USA), 3115 Stanford St., 
Dallas, TX 75225-7702 or ATC/ERSO/ 
ITRI, Building 11, 195-4-E000, Sec 4 
Chung-Hsing Rd., Chu-tung, Hsinchu, Tai¬ 
wan, ROC. Inquiries or nominations may 
also be made by phone to (214) 750-4986 
or fax (214) 750-4999 anywhere from USA 
or 886-35-942997 or fax 886-35-953598 
elsewhere. 


NAVAL POSTGRADUATE SCHOOL 
Computer Science 

The Computer Science Department in¬ 
vites applications for faculty positions at all 
levels. Our primary interests are in the areas 
of operating systems and programming lan¬ 
guages. Our secondary interests are in the 
areas of visual data processing, graphics, 
and computer architecture (especially real¬ 
time and parallel-processing aspects of the 
three). Applicants should have a Ph.D. in 
Computer Science or a closely related field 
and be committed to high-quality teaching 
and research. Senior applicants must have 
distinguished research records. Appoint¬ 
ments can begin at any time. 

The Department offers M.S. and Ph.D. 
degrees in computer science, but no under¬ 
graduate degrees. Currently, 110 students 
are enrolled in the M S. program and five in 
the Ph.D. program. Students are military of¬ 
ficers or civilian employees of the Depart¬ 
ment of Defense and are fully supported by 
their sponsoring organization during their 
studies. Departmental facilities (supported 
by eight full-time computer professionals) in¬ 
clude six instructional and research labora¬ 
tories with extensive state-of-the-art equip¬ 
ment. Faculty normally teach for two quarters 
and perform research for two quarters per 
year. The Monterey-Carmel area provides a 
pleasant coastal climate and easy access to 
Silicon Valley companies. 

Send a detailed resume, an abstract of 
your best recent research, and letters of 
reference to Faculty Search Committee, 
Computer Science, Code 52, Naval Post¬ 
graduate School, Monterey, CA 93943 
(phone (408) 646-2449). An Equal Oppor¬ 
tunity/ Affirmative Action Employer. 


UNIVERSITY OF MIAMI 
Victor P. Clarke Chair 
in Computer Engineering 

The Department of Electrical and Com¬ 
puter Engineering of the University of Miami 
invites nominations and applications for the 
recently established Victor P. Clarke Chair in 
Computer Engineering. It is expected that 
candidates will have an outstanding reputa¬ 
tion in research, an established record in 
external funding, and a commitment to the 
development of computer engineering 
education in the Department. Preferred 
areas of interests are computer architecture, 
computer graphics, computer networks, 
computer vision, expert systems, parallel 
processing, and real-time systems. Salary 
and other benefits are competitive. 

The Department offers B.S., M.S. and 
Ph.D. programs in Electrical and Computer 
Engineering. Approximately ten of the twen¬ 
ty faculty are in Computer Engineering/Sci- 
ence. The University is located in beautiful 
Coral Gables, a suburb of Miami, FL. Nomi¬ 
nations/applications should be sent with the 
names of five references to: Dr. Tzay Y. 
Young, Acting Chair, Department of Elec¬ 
tncal and Computer Engineering, P.O. Box 
248294, University of Miami, Coral Gables, 
Florida 33124. The University of Miami is an 
equal opportunity/affirmative action 
employer. 


OREGON INSTITUTE 
OF TECHNOLOGY 

Oregon Institute of Technology, the poly¬ 
technic college for the State of Oregon, is 
searching for two faculty members effective 
September, 1989. Both positions are fixed- 
term, nine-month positions in the Computer 
Systems Engineering Technology Depart¬ 
ment. MSEE, MSCE or equivalent required, 
Ph.D. preferred. Applicants should possess 
a commitment to teaching and have recent 
industrial experience in several of the follow¬ 
ing areas: microprocessor systems, digital 
design, automated design techniques (CAE), 
C and UNIX programming. Responsibilities 
include: teaching, laboratory and course 
development and applied research with in¬ 
dustry. Applications along with the names 
and phone numbers of at least three refer¬ 
ences should be sent to: Ms. Shelby Wils- 
don, Director of Personnel, O.I.T., 3201 
Campus Drive, Klamath Falls, OR 97601- 
8801, (503) 882-2798. Deadline for receipt 
of applications is June 15, 1989. OIT is an 
AA/EOE. 


THE FLINDERS UNIVERSITY OF 
SOUTH AUSTRALIA 
Discipline of Computer Science 
Associate Professor in 
Computer Science 
(Limited term) 

The University seeks an academic of high 
standing with proven abilities across the 
range of academic activities. The incumbent 
will be expected to lend strong support to the 
Chair of Computer Science (presently vacant) 
in the management of the Discipline and the 
pursuance of various external initiatives. 
From time to time, the incumbent may be 
called upon to Head the Discipline. The 
position is available from 1 July, 1989, for a 
period of up to 5 years. Further extension 
may be possible. 

The Discipline of Computer Science offers 
a full major, honours programme and the 
range of postgraduate opportunities. Stu¬ 
dent enrollments in successive years number 
approximately 400, 105, 75 and 10. 
Machines used for teaching and research in¬ 
clude two Sun 4/260’s, a Sun 3/280, 14 
Sun workstations and various personal com¬ 
puters. The Discipline presently comprises 
18 members of staff, including nine positions 
at lecturer or above. Staff research covers a 
wide range. Further information may be ob¬ 
tained from Associate Professor M. J. Brooks 
(telephone (08) 275-2662, electronic mail 
mjb@cs.flinders.oz.au.). 

Salary: $A53,670 

(Opportunities exist for supplements via 
consulting, external courses, and a 
negotiable retention allowance.) 

Written applications giving full details of 
qualifications and experience, and the 
names and addresses of three referees of 
whom confidential enquiries may be made, 
should be forwarded, in duplicate, to the 
Director of Administration and Registrar, 
The Flinders University of South Australia, 
Bedford Park, S.A. 5042, Australia by 16 
June 1989. 

Equal Employment Opportunity is Uni¬ 
versity Policy. 
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IEEE Computer Society Workshop 
on 

ARTIFICIAL 

_i INTELLIGENCE 

.1 W FOR 

COMPUTER VISION 

Sheraton Grand Hotel on Harbor Island 
San Diego, California - June 5,1989 



General Chair: 

Professor R. Chellappa 
University of Southern California 

Program Co-Chairs: 

Prof. J.K. Aggarwal 
University of Texas at Austin 
Prof. A. Rosenfeld 
University of Maryland 


The workshop will address the following issues: 

1. Why Al should be incorporated into computer vision systems? 

2. How can this best be done? 

3. How successfully has it been done in the past? 

A preliminary list of speakers and their topics are as follows: 

Morning 8:30-10:00 

1 . 

L.N. Kanal, University of Maryland 

"Al, Pattern Recognition, and Computer Vision" 


2. 

J.K. Tsotsos, University of Toronto 
"Computational Complexity Constraints for 

Visual Information Processing" 


3. 

A.C. Kak, Purdue University 
"Spatial Reasoning" 

10:00-10:30 


Coffee Break 

10:30-12:30 

4. 

J.W. Roach, Virginia Polytechnic Institute 

and State University 

"Al in Industrial Machine Vision" 


5. 

S.N. Srihari, State University of N. Y. at Buffalo 
"Al in Document Image Analysis" 


6. 

D.M. McKeown, Jr., Carnegie Mellon University 
"Al in the Analysis of Aerial Imagery" 


7. 

N. Nandhakumar, University of Texas 
"Application of Al in Multisensory Vision" 

12:30-2:00 


Lunch 

Afternoon 2:00-4:00 


Panel Session 

Moderators: 

J.K. Aggarwal Panelists: L.N. Kanal S.N. Srihari 


A. Rosenfeld J.K. Tsotsos D.M. McKeown, Jr. 

A.C. Kak N. Nandhakumar 

J.W. Roach 


Registration Information: 

IEEE Members 
Non-Members 
Student Members 


Preregistration 
Before Mav 1.1989 

$50 

$65 

$25 


Registration 
After Mav 1. 1989 

$60 

$75 

$25 


'Please make all checks payable to : AICV '89 

and send to: Mrs. Linda Varilla 

Signal and Image Processing Institute 
University of Southern California 
PHE 306 , University Park 
Los Angeles, CA 90089-0272 


•EEE Computer Society The Institute of Electrical and Electronics Engineers, Inc. 













CALL FOR PAPERS 



17th International Symposium on 


Computer Architecture 

Seattle, Washington 
May 28-31,1990 

sponsored by 

® IEEE Computer Society 

^ Institute of Electrical and Electronics Engineers (IEEE) 

Bern Association for Computing Machinery 


SYMPOSIUM COMMITTEE 

Program Chair: 

James Goodman 
Computer Sciences Department 
University of Wisconsin 
1210 W. Dayton 
Madison, Wisconsin 53706 
608-262-1204 


Conference Co-Chairs: 
Jean Loup Baer 
University of Washington 
206-543-1695 
Larry Snyder 
University of Washington 
206-543-1695 


Treasurer & Local Arrangements Chair: 
Hank Levy 

University of Washington 
206-543-9204 


Tutorial Chair: 

Gurinadar Sohi 
University of Wisconsin 
608-262-1204 


Publicity & Publications Chair: 

Shreekant Thakkar 
Sequent Computer Systems 
503-627-9822 


Submitted papers will be accepted for consideration until Novem¬ 
ber 21,1989. Five copies of the double-spaced manuscript, in 
English, not exceeding 6000 words in length, should be sent to 
Program Chair. A single cover sheet should be included which 
contains: paper title, full names, affiliations, complete addresses, 
and phone numbers of the authors. E-mail addresses should be 
included if available. 

Papers are solicited on any aspects of Computer Architecture. 
Topic areas included, but are not limited to, 

■ Non-numeric architectures 

■ Novel computing techniques 

■ Distributed and parallel architectures 

■ Language and operating systems support 

■ Application-specific architectures 

■ Performance evaluation and measurement 

■ Technology impact on architecture 

■ Memory systems 

■ Very-high performance architectures 


Because the identity of the authors will not be revealed to the 
referees, authors’ names and affiliations should appear only on 
the cover sheet. Authors should avoid references and citations 
that compromise anonymity. 

Notification of acceptance will be given by February 9,1990. 
Authors of accepted papers will be requested to submit a final, 
camera-ready copy by March 12,1990. 

Tutorials will be held on May 28,1990. Send five copies of 
proposals for full or y 2 day tutorials to the Tutorials Chair to 
be received by November 28,1989. Proposals should include: 
tutorial title, outline, brief description of topics to be covered, 
intended audience, assumed attendee background, and a resume 
of the speaker. 









BOOK REVIEWS 


Editor: Wiley McKinzie, School of Computer Science and Technology, Rochester Institute of Technology, Rochester, NY 14623; Compmail, w.mckinzie; CSnet, wrm@rit 


Object-Oriented Database Programming 

Suad Alagic (Springer-Verlag, New York, 1989, 320 pp., $45) 


This book is intended as a textbook for 
a course in computer programming, not 
as a reference book. Toward that end, 
each chapter ends with lengthy program¬ 
ming exercises covering specific areas 
presented in the chapter. Alagic states in 
the preface that “introductory program¬ 
ming languages like Pascal and Modula- 
2, and the familiarity with the very basic 
notions of modern mathematics are all 
that is required to use this book.” How¬ 
ever, the back cover states that this book 
is “intended for upper-level undergradu¬ 
ate and graduate students, as well as for 
computer professionals whose work in¬ 
volves databases and programming lan¬ 
guages.” Given the advanced concepts 
presented in the book, the latter state¬ 
ment better reflects the desired back¬ 
ground for the reader. The heavy pro¬ 
gramming examples and the inferences 
made through these examples limit the 
book’s suitability for the classroom. 
Consequently, I also do not recommend 
this book for self-instruction. 

The book is technically difficult, since 
over 60 percent of the text consists of 
programming language notation. The 
reader must carefully decipher what the 
author is attempting to convey via the 
programming examples. In a way, read¬ 
ing this book is like trying to understand 
the internals of a program without in-line 
comments. The reader must invest a 
great deal of time to learn anything at all. 
My main complaint, therefore, is with 
the format of the material rather than the 
material itself. 

The title is misleading. A more de¬ 
scriptive title for this book would be 
Modulex: An Object-Oriented Program¬ 
ming Environment. I assumed from the 
actual title that the book offered a discus¬ 
sion of object-oriented programming in¬ 
volving some type of object-oriented 
database management system. The ma¬ 
jority of this work, however, deals with 
the Modulex programming environment. 

It never refers to any DBMS except to 
compare object-oriented approaches to 
the relational model. While it is heavily 
oriented toward database structures (such 


as records, sets, and tables), the term 
“database environment” really just refers 
to object-oriented data structures sup¬ 
ported by object-oriented software, in¬ 
cluding some DBMS-related features. 

According to Alagic, “the major topic 
of this book is the integration of data and 
programming languages and the associ¬ 
ated methodologies.” The book is seem¬ 
ingly self-contained, although Alagic 
gives a large number of references at the 
end of every chapter. Alagic does cover 
most aspects of his stated topic, from 
data types to procedures, from design 
methodology to standard abstractions. 

The book’s heavy reliance on Mod¬ 
ulex, which is not available or supported 
commercially, is unfortunate because ac¬ 
tual programming done by the reader 
cannot be verified by program execution. 
Readers might be more inclined to try 
the programming exercises with a com¬ 
mon object-oriented language. In addi¬ 
tion, because 60 percent of the text con¬ 
sists of program examples, the reader 
must learn Modulex before being able to 
understand the book’s underlying con¬ 
cepts. While Modulex serves as a learn¬ 
ing tool, the time needed to learn the lan¬ 
guage outweighs the benefits of its use. 

Otherwise, the book’s structure is 
sound. The text builds on itself, chapter 
by chapter. For instance, the introduction 
contains definitions and a number of ba¬ 
sic concepts used throughout the text, 
such as aggregation, generalization, and 
covering. This introduction must be read 
and learned thoroughly before proceed¬ 
ing with subsequent chapters. 

Chapter 1 confronts the reader with 
one of the most hideous openings to a 
book I have seen. Without introduction, a 
definition of entity sets is presented. No 
words, just an entity set definition. This 
rather sharp opening uses set notation 
presented in the introduction. Readers 
who only skim the introduction will be 
forced to back up to the introduction to 
learn the set notation. The rest of the 
chapter defines the Modulex program¬ 
ming environment notation, including 
variable definition, record definitions, 


and actions. Modulex is object-action 
oriented. This chapter also includes such 
topics as schema synthesis algorithms 
and a comparison to the relational data 
model, although these seem out of place 
considering the other areas covered in 
the chapter. 

The next two chapters deal with proce¬ 
dures, module definitions, and design 
methodology of procedures, all further¬ 
ing the definition and development of the 
Modulex environment. One of the more 
interesting and readable chapters deals 
with design methodology. Alagic covers 
abstraction, localization, refinement, in¬ 
cremental design, actions, and transac¬ 
tion development. Distinctions between 
object- and relational- oriented proce¬ 
dures are also discussed and compared. 

The chapter on standard abstractions 
covers areas such as aggregation, gener¬ 
alization (including inheritance and spe¬ 
cialization), recursion, and covering. It 
ends with a lengthy application example. 
Because of the very technical nature of 
this subject and the need to reemphasize 
key points, all chapters should include 
summaries. However, the book contains 
only one chapter summary. Instead, each 
chapter ends with a number of exercises. 
Regardless of the book’s intended use as 
a textbook, chapter summaries would 
have been more useful. 

The final chapter covers I/O program¬ 
ming, including data validation, screen 
I/O, and file or stream I/O. This is the 
most readable chapter — not surpris¬ 
ingly, it also contains the fewest program 
examples. The book concludes with a se¬ 
lected biography, as well as author and 
subject indexes. One final shortcoming is 
a lack of diagrams, tables, or (given the 
format of the text) flowcharts. 

While this book is a strong contender 
as a textbook in an advanced program¬ 
ming class, its use as a reference book or 
self-learning guide is severely limited. I 
recommend looking elsewhere if you in¬ 
tend to learn this subject on your own. 

Jeff S. Ebert 

Unisys 


May 1989 
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Fundamentals of MOS Digital Integrated Circuits 

John P. Uyemura (Addison-Wesley, Reading, Mass., 1988, 624 pp„ $52.75) 


Many recent textbooks on the design 
and analysis of VLSI circuits emphasize 
engineering aspects of the technology, 
usually featuring just a chapter or two on 
physics and the analysis of MOS devices. 
Authors probably take this “practical” 
approach so students can learn the tech¬ 
niques quickly. 

But a good, fundamental knowledge of 
device modeling and analysis is essential 
to designing high-performance systems. 
Such knowledge also helps in critiquing 
emerging, but poorly defined, technolo¬ 
gies. 

The book under review is devoted en¬ 
tirely to the design and analysis of digital 
integrated circuits, with emphasis on 
analysis. The book covers device physics 
at a basic level, but it only discusses cir¬ 
cuit layout and fabrication in summary 
form as needed. Device physics, fabrica¬ 
tion, system logic, and analysis are dis¬ 
cussed as used in interacting environ¬ 
ments. This is clearly a “foundation” 
book for circuit and system designers. 

The book has 10 chapters, an appendix 
summarizing pn-junction properties, and 
an index. It deals with NMOS and 


CMOS circuits almost equally. The de¬ 
sign of digital ICs is based on the ap¬ 
proximate models (called square-law 
models) of MOS field-effect transistors 
(MOSFETs). Access to a computer while 
using the book is desirable but not essen¬ 
tial, since readers can solve most of the 


It is not an easy book for 
self-study, unless the 
reader is already involved 
in chip design. 


equations with a scientific calculator. 

The book’s strong point is the use of 
Basic and Spice programs, along with the 
resulting printouts, to illustrate the calcu¬ 
lation of voltages and currents (and their 
relationships). 

The first four chapters discuss 
MOSFETs and their models (in the form 
of equations), the DC characteristics of 
NMOS and CMOS inverters, the errors 
involved in modeling, the effects of 


“downsizing” MOSFETs as required by 
VLSI, and the corrections involved in 
downsizing. 

Chapter 5 examines fabrication, relat¬ 
ing the process to equations developed 
earlier. The last five chapters deal with 
the design and analysis of NMOS and" 
CMOS logic gates, flip-flop^, synchro¬ 
nous CMOS logic, timing problems, and 
the structural approach to MOS logic (for 
example, programmable logic arrays). 

The book is appropriate for a two- 
quarter graduate-level course. I certainly 
recommend it for students and chip de¬ 
signers who wish to study the modeling 
and analysis of MOSFETs in detail. It is 
not an easy book for self-study, unless 
the reader is already involved in chip de¬ 
sign. The book is well written and pres¬ 
ents problems at the end of most chap¬ 
ters. References for further research are 
provided at the end of each chapter. 

In summary, this useful book fills an 
important gap in the textbooks on VLSI 
design. 

Arun Ektare 

Mesa State College 


Optical Computing: A Survey for Computer Scientists 

Dror G. Feitelson (MIT Press, Cambridge, Mass., 1988, 393 pp., $39.95) 


As stated in the preface, this book was 
“written by an outsider, for outsiders.” 

As such, it is intended to give the com¬ 
puter science world a survey of the wide 
and growing field of optical computing. 
Early in the preface, Feitelson points out 
the dilemma he faced in writing the 
book: whether to provide a breezy but 
shallow introduction or a more substan¬ 
tive work suitable for direct and immedi¬ 
ate application. Regrettably, he chose a 
course between the two, creating too am¬ 
bitious a project for reasonable coverage 
on more than a cursory level. However, 
Feitelson valiantly fought his losing 
battle and clearly learned a large amount 
about optical computing. 

While the book does not provide a rea¬ 
sonable introduction for computer scien¬ 
tists not versed in optics, Feitelson has 
clearly captured a large and diverse 
amount of information on a quickly 
growing field in less than 400 pages. 

This is both to his credit and the reader’s 
loss. He tells beginners more than they 
can use and experts less than they need. 
Feitelson covers the material through 
heavy use of tables, diagrams, and lists at 


the expense of detailed, worked-out ex¬ 
amples. The reader would do better to 
make this the second (or third) book in a 
sequence starting with introductory ma¬ 
terial on optics in general and optical en¬ 
gineering in particular. 

Feitelson began the book as a master’s 
thesis, and it contains much of the heavy 
academic style common in such works. 
More than 750 references are carefully 
keyed to relevant portions of the text. 

The bibliography is over 50 pages in 
length. There is also a half-page explain¬ 
ing the metric system. In reading the 
book, I felt as though I were being ex¬ 
posed to Feitelson’s first encounters with 
the various topics. 

If the previous commentary has not 
cooled your interest in optical comput¬ 
ing, this book will provide the dedicated 
reader a tour through this fascinating and 
increasingly important field. I do not 
know of any similar compendium. Top¬ 
ics include a brief summary of optics, 
image and signal processing, optical nu¬ 
meric processing, electro-optic systems, 
nonlinear optics, digital optics, current 
technology, prospects for future develop¬ 


ment, and the potential for optical com¬ 
puters to undergo evolution similar to 
electronic computers. Appendixes cover 
classification, linear algebra, Fourier 
transforms, lasers, semiconductors and 
light, holography, crystals, waveguides, 
and the CRDCW (Concurrent Read Du¬ 
plicate Concurrent Write) model. 

Unfortunately, this book is not suitable 
for classroom use. It does not provide the 
necessary depth for an advanced course, 
and it lacks traditional student aids for an 
introductory course such as worked-out 
examples, review questions, and student 
problems. Lastly, the appendixes are 
very short. All nine take up 32 pages, 
with the longest being the one on the 
Fourier transform at eight pages. 

I recommend this book to those read¬ 
ers either earnestly interested in optical 
computing and willing to live with this 
less-than-perfect book or sufficiently 
versed in the field to find these short¬ 
comings immaterial. 


Robert E. Cousins 
Data General 
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An Introduction to Object-Oriented Programming and Smalltalk 

Lewis J. Pinson and Richard S. Wiener (Addison-Wesley, Reading, Mass., 1988, 502 pp., $26.95) 

An Introduction to Object-Oriented Programming and C++ 

Richard S. Wiener and Lewis J. Pinson (Addison-Wesley, Reading, Mass., 1988, 273 pp., $26.95) 


Object-oriented programming (OOP) 
has garnered keen interest lately because 
of the potential economic benefits that 
many software development projects 
could gain from its techniques. Easier 
long-term maintenance, extensibility, 
and software reusability are three main 
advantages of this approach. 

But OOP does have drawbacks. It 
generally requires much larger, more 
powerful computers to achieve accept¬ 
able performance. Traditional procedural 
languages came into vogue because they 
made programming tasks easier when 
compared to assembly language pro¬ 
gramming. Execution time may have suf¬ 
fered, but this compromise was consid¬ 
ered acceptable. 

OOP represents the next level of lan¬ 
guage evolution and a very promising 
replacement for third-generation lan¬ 
guages. Many object-oriented program¬ 
ming languages (OOPLs) are in commer¬ 
cial use today, including Smalltalk-80, 
Smalltalk/V, Actor, Eiffel, and Objec- 
tive-C, although some also require their 
own operating environment. 

There are also extensions to existing 
languages to make them more object- 
oriented. Some examples here would in¬ 
clude Ada, C, and Modula-2. The exten¬ 
sion to C is named C++ and is largely the 
work of Bjame Stroustrup of AT&T Bell 
Laboratories. C++ is an evolving exten¬ 
sion that is destined to become a full- 
fledged OOPL in its own right. 

For all its promise, end-user accep¬ 
tance has been slow. Perhaps one reason 
for this has been the lack of suitable 
books and texts with which potential us¬ 
ers could learn at their own pace. Since 
OOP is a new programming paradigm, 
many programmers become confused 
when attempting to grasp the essentials 
or understand the terminology. What 
they learned through on-the-job experi¬ 
ence is largely not applicable to this 
methodology. It is certainly different! 

The two works by Pinson and Weiner 
attempt to address this problem. To be 
successful, any new OOP text must ex¬ 
plain the subject matter succinctly but 
comprehensively. Pinson and Weiner 
clearly achieve this in the Smalltalk vol¬ 
ume, but are less successful in the C++ 
book. 

Both books are aimed at the experi¬ 
enced programmer. The authors start 
each volume by defining OOPL as a lan¬ 


guage that embraces such concepts as 
abstraction, encapsulation, inheritance, 
and polymorphism. (Other authors might 
add to this list.) They then use examples 
to explain these terms. 

The Smalltalk version is lavish in its 
use of examples, figures, and listings. 
The source code listings are an integral 
part of the book. Although source code 
might be unexciting to some readers, it is 
perhaps the only way to thoroughly and 


Professional programmers 
should find the time 
invested in learning OOP 
through Smalltalk to be 
time well spent. 


comprehensibly grasp the fundamentals 
of any language. The choice of object 
names and the syntax of Smalltalk make 
the language readily understandable. 
There is little in the way of hieroglyphics 
or compacted statements. 

The authors take the reader through 
objects and classes, adding new classes, 
input/output operations, magnitude and 
collection classes, and streams. Three 
appendixes document the Smalltalk syn¬ 
tax and protocol summaries of both 
methods and classes discussed in the 

Chapter 10 brings much of the instruc¬ 
tional material together in an inclusive 
and interesting bank simulation problem, 
complete with multiple tellers, custom¬ 
ers, and queues. The program is further 
developed in Chapter 11 by providing a 
graphics enhancement in the form of an 
animation. 

The C++ book assumes a prior knowl¬ 
edge of C, although two chapters serve 
as a quick review and a description of 
the syntactical extensions of C++. Al¬ 
though C++ is not yet considered a full 
OOPL, it eventually will become more 
than just an extension of C. Most C++ 
implementations tend not to be true com¬ 
pilers but interpreters that preprocess the 
C++ code into C code, which in turn is 
compiled into a finished program. 

Previously, the only way to learn C++ 


was through Stroustrup’s The C++ Pro¬ 
gramming Language or possibly a tuto¬ 
rial provided by a C++ software vendor. 
Pinson and Weiner’s C++ book offers an 
alternative. 

I did find the authors’ description of 
the various concepts somewhat sparse, 
although adequate. The book contains 
many lengthy code listings that demon¬ 
strate the various topics. 

The authors rely on the elegance of 
their code as the principal instructional 
tool. They claim to have thoroughly 
tested and debugged the code, and their 
extensive and well-developed examples 
lend credibility to that statement. How¬ 
ever, C (and therefore C++) is a systems 
programming language. Reading the 
lengthy listings does prove to be tedious 
at times, even if given simple examples. 

Of particular interest, however, is the 
inclusion of three case studies: a spelling 
checker, a bank teller simulation, and an 
interactive function evaluator. Careful 
examination and understanding of these 
will take a potential C++ programmer 
far. 

Additionally, the C++ book assumes 
an understanding of such topics as linked 
lists, trees, and finite state automata, all 
of which are implemented as C++ pro¬ 
grams. A typical commercial program¬ 
mer might not understand nor fully ap¬ 
preciate such examples. Hence, the book 
is targeted for the high-level reader. 

I especially recommend the Smalltalk 
book as a way to learn OOP. The reader 
will come away with a thorough grasp of 
OOP fundamentals and understand the 
creation, classification, and communica¬ 
tion between objects. I also highly rec¬ 
ommend it simply to learn Smalltalk. 

Smalltalk is useful as a prototyping 
language for user interfaces, especially 
highly interactive full-screen user inter¬ 
faces. Hence, a professional programmer 
should find the time invested in learning 
OOP through Smalltalk to be time well 
spent. 

The C++ book is not as useful for 
learning OOP, but an advanced program¬ 
mer with a thorough knowledge of C 
should come away with the ability to 
program in C++. I therefore recom¬ 
mend it to C programmers who wish to 
become C++ programmers. 

Richard G. Estock 

EDP Consultants 


May 1989 
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Computer Integrated Manufacturing: The Data Management Strategy 

Olin H. Bray (Digital Press, Bedford, Mass., 1988, 341 pp., $45) 


Computer integrated manufacturing is 
a buzzword with wide usage and even 
wider variation in definition. Everyone 
wants it, but few seem to understand 
what is really is. This book is the first of 
four books on CIM from Digital Press. 
While it is not perfect, this book gets the 
series off to a strong start. 

Bray asserts that the key to computer 
integration is an integrated data-manage- 
ment strategy. He then builds on this 
premise, showing how to develop and 
utilize such a strategy. Along the way, he 
presents a wide range of considerations 
and concerns vital to anyone considering 
CIM. 

The value of this book extends far be¬ 
yond those few individuals involved in 
CIM planning. Many of Bray’s observa¬ 
tions and explanations also apply to the 
functional areas that are combined in a 
CIM solution, even when these areas are 
implemented in a stand-alone fashion. 
Among the data-management needs dis¬ 
cussed are those of computer-aided de¬ 
sign and engineering, configuration man¬ 
agement, process planning, robotics, 
quality control, and flexible manufactur¬ 
ing systems. He develops a general infor¬ 
mation model for each area, discussing 
how suitable databases could support 
particular functions. 

Bray wraps up the book with a look at 
the challenges in managing a CIM proj¬ 
ect: from organizing a functional task 
force to selecting vendors and database 
management systems. However, the bulk 
of the book is the technical discussion of 
the component CIM functions and how 
they fit together. The treatment of man¬ 
agement issues, such as the introductory 
discussion of the importance of CIM and 
data-management technology, is more 
suitable as checklists for the knowledge¬ 
able reader than as tutorial coverage. For 
example, the author’s discussion of man¬ 
aging change refers to the change pro¬ 
cess as defined in Wilson Learning Cor¬ 
poration’s seminar, “Managing in a 
Changing Environment.” Since the book 
never defines the steps in the process, 
anyone unfamiliar with the seminar must 
research the references to make sense of 
the section. 

The key to benefiting from this book, 
however, is knowing (or being willing to 
learn) Nijssen Information Analysis 
Methodology. NIAM, a fact-based infor¬ 
mation-modeling methodology for infor¬ 
mation analysis, provides a formal ap¬ 
proach to identifying the information 
model required to support a set of appli¬ 
cations or a database design. Bray de¬ 


votes a chapter to explaining NIAM, and 
unless the reader is already familiar with 
the methodology, I don’t recommend 
skipping it. 

At the same time, I do not wish to im¬ 
ply that only expert database designers 


The information is vital 
for system designers and 
application managers 
applying computers to 
manufacturing, business, 
and engineering. 


should read this book. The information is 
vital for system designers and applica¬ 
tion managers applying computers to 
manufacturing, business, and engineer¬ 
ing. One of its benefits is a common 


Software development methodology. 

Authors Daniel C. Morris and Joel S. 
Brandon explain how to integrate the de¬ 
sign of online software with the design 
of specific business operations using Re¬ 
lational Systems Devlopment (ISBN 0- 
07-043198-1, 195 pp., $44.95). This new 
software development methodology com¬ 
bines project planning and control with 
actual development techniques, while of¬ 
fering the flexibility to incorporate 
emerging technologies. Separate sections 
of the book examine business analysis, 
defining business requirements, logical 
systems design, and incremental devel¬ 
opment, testing, and implementation. 

Contact McGraw-Hill, 11 West 19th 
St., New York, NY 10011, phone (800) 
262-4729. 

Parallel processing. More than 15 au¬ 
thorities in the field of parallel process¬ 
ing have contributed material to Parallel 
Processing for Supercomputers and Arti¬ 
ficial Intelligence (ISBN 0-07-031606-6, 
673 pp., $54.95), edited by Kai Hwang 
and Douglas DeGroot. Contributing au¬ 
thors examine such topics as vector proc- 


frame of reference that lets different spe¬ 
cialties communicate their needs and 
concerns in implementing computer-inte¬ 
grated solutions. The key to computer in¬ 
tegration is not computer networks; it is 
the ability to access accurate, timely in¬ 
formation. The network simply provides 
a means of moving data from one ma¬ 
chine to another; the information repre¬ 
sented by that data, whether formalized 
in a database or not, provides the value. 

This book introduces the world of 
computer-integrated information. While 
it is not easy reading, it is definitely 
worth reading. (The other books in the 
series, CIM: The Information Engineer¬ 
ing Methodology by Paul S. Thompson, 
CIM: Parallel Processing and High Per¬ 
formance by Peter C. Patton and Olin H. 
Bray, and The Human Side of Enterprise 
Integration: CIM and Networking in the 
Nineties by Charles M. Savage, are 
promised in the spring, fall, and winter 
of 1989, respectively.) 

Vincent C. Jones 

Ft. Collins, Colo. 


essors and multiprocessors, concurrency 
control, hypercube systems and key ap¬ 
plications, parallel architectures for im¬ 
plementing AI systems, and a compari¬ 
son of the Cray X-MP-4, the Fujitsu VP- 
2000, and the Hitachi S-810/20. 

Contact McGraw-Hill, 11 West 19th 
St., New York, NY 10011, phone (800) 
262-4729. 

IC design specifications. The three- 
volume, softbound IC Master has been 
updated to include design specifications 
for 12,000 new ICs and over 150,000 al¬ 
ternate source devices. Volume 1 is a 
guide to more than 80,000 standard ICs, 
grouped by basic category. Volume 2 in¬ 
cludes over 1,200 manufacturers' data 
pages and addresses and phone numbers 
for every IC manufacturer. Volume 3’s 
guide to custom/semicustom ICs in¬ 
cludes gate array, cell-based ASICs, and 
programmable logic. 

The set is $140, plus $10 for shipping 
and handling. Contact Marie Botta, 
Hearst Business Communications, 645 
Stewart Ave., Garden City, NY 11530, 
phone (516) 227-1300. 
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IEEE standards used throughout the industrial world. 

Technical Committees. More than 30 TCs publish newsletters, 
provide interaction with peers in specialty areas, and directly 
influence standards, conferences, and education. 

Conferences/Education. The society holds about 100 
conferences each year and sponsors many educational activities, 
including computing science accreditation. 

Chapters. Regular and student chapters worldwide provide the 
opportunity to interact with colleagues, hear technical experts, and 
serve the local professional community. 

European Office 

Payments for Computer Society membership and publication 
orders are accepted by checks in Belgian, British, German, 
Japanese, Swiss, or US currency. Checks in US funds must be 
drawn on a US bank. Payment may also be made by American 
Express, Diners Club, Eurocard, Master Card, or Visa credit cards. 


Asian Office 

Payments for Computer Society membership and publication 
orders are accepted by checks in Japanese or US currency. Checks 
in US funds must be drawn on a US bank. Payment may also be 
made by electronic fund transfer to the Bank of Tokyo, Akasaka 
Branch, Toza acct. 0767956; the credit receiver is the IEEE 
Computer Society Headquarters Office. Payment may also be made 
by American Express, Diners Club, Eurocard, Master Card, or Visa 
credit cards. 


Ombudsman 

Members experiencing problems — magazine delivery, 
membership status, or unresolved complaints — may write to the 
ombudsman at the Publications Office. 
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Announcing new 

SIMSCRIPT II.5 with SIMGRAPHICS 


Simulation models are now easier to build 
-results are easier to understand 


N ow you can provide the users 
of your SIMSCRIPT II.5 
models with SIMGRAPHICS™ 
-graphical input and animation. 

Results are easy to understand- 
an animated picture, histograms, 
pie charts and plots. 

Because simulation results are 
easily understood, your recommen¬ 
dations are more likely to be acted 
upon. 

Simulation simplified 

SIMSCRIPT II.5 gives you a 
compact English-like language. 
Your simulation program reads like 
a description of the system you are 
studying. 

Your model development, check¬ 
out, modification and enhancement 
are greatly simplified. 

Many successful applications 
SIMSCRIPT II.5® is a well 
established, standardized, and 
widely used language with proven 
software support. 

Typical applications include: 
military planning, manufacturing, 
communications, logistics, and 
transportation. 


Free trial offer 

The free trial contains every¬ 
thing you need to try SIMSCRIPT 
II.5 on your computer. 

Try the SIMSCRIPT II.5 lan¬ 
guage, the quality and timeliness 
of our support, the accuracy of 
our documentation and the 
facilities for error-checking— every¬ 
thing you need for a successful 
project. 

For 26 years CACI has provid¬ 
ed trial use of its simulation 
software-no cost, no obligation. 
Act now -free training offer 

For a limited time we also in¬ 
clude free training. Call today to 
avoid disappointment-class size is 
limited. 

SIMSCRIPT II. 5 is available on 
most popular computers including 
PC’s running under OS/2, the 
Mac II, and workstations. 

For immediate information 

Call Doug Dittrich at (619) 
457-9681, or FAX (619) 457-1184. 
In Europe, call Richard Eve on 
(01) 528-7980, FAX (01) 528-7988. 


I Rush information on 
SIMSCRIPT II.5 with 
SIMGRAPHICS free trial and 
training 

Free trial-learn the reasons for the 
broad and growing popularity of 
SIMSCRIPT II.5. 

No cost, no obligation. 

Limited offer-return the coupon today 
and we will include one free course enroll¬ 
ment worth $950. 

□ Send information on your Special 
University Offer. 


Return to: IEE 

CACI Products Company 
3344 North Torrey Pines Court 
La Jolla, California 92037 

Call Doug Dittrich at (619) 457-9681 
FAX (619) 457-1184 
In Europe: 

CACI Products Division 

Regent House, 89 Kingsway 

London WC2B 6RH, United Kingdom 

Call Richard Eve on (01) 528-7980 
FAX (01) 528-7988 
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